[Proposal] Inferring Parameters from Other Parameters

[jackos]

Hi all, this feature request: #1245 came up during the first Mojo language committee meeting, and @Mogball has put forward a proposal to enable this with an inferred keyword:

fn scalar_func[inferred dt: DType, x: Scalar[dt]]() -> Scalar[dt]:
    return x * 2

print(scalar_func[Int64(5)]())

The full proposal is here

We'd love to hear from the Mojo community before going ahead with the implementation, any comments or questions are welcome!

[jymchng]

Good idea - just curious why doesn't Mojo use present tense in its keywords, e.g. borrow instead of borrowed, infer instead of inferred etc?

[gryznar]

Good question! Sense will be kept, but the form will be shorter :)

[melodyogonna]

Always wondered this as well.

[Mogball]

Not a definitive answer, but I find from the perspective of the function author, it makes more sense to declare an argument as being borrowed and owned, meaning that the function argument is "borrowed" from the caller or "owned". "borrow" as a verb makes more sense to describe a function, such as ptr.borrow(), or the act of calling a function with a borrowed argument.

[leandrolcampos]

Thanks for this proposal! I'm very happy with it.

[soraros]

Let's give the feature/proposal a better name. It's really about introducing "inferred only parameter".

[Mogball]

Sure, I think this might be better. I titled it with respect to the main problem it is intended to solve, but it does enable other things.

[soraros]

Or "implicit parameter". Also used by Coq, Agda, Scala(?).

[ivellapillil]

Although keword parameter is more verbose, we can probably start with that and avoid having a new inferred keyword? For me personally, inferred makes the call site a bit confusing. With keyword parameters call site is more explicit and the reader can understand what is happening without having to look into the definition site..

[Brian-M-J]

How would this work in situations where the type to return can't directly be inferred?

Example 1

Suppose I were to write a function that returns the last element of a heterogeneous list:

alias het_list = [1, True, "Hello", (2, 3, 4)]

fn last_element[inferred T: ??, input_list: ListLiteral]() -> T:
    return input_list[-1]

How can I infer the data type of the last element of input_list so I can annotate the function properly?

Example 2

This example is much more practical: Inspired by the |> operator in many programming languages, I wanted to make a function to emulate that behaviour (it's Pythonic to prefer explicit functions over confusing symbols). Here is the function in Python:

from functools import reduce

def pipeline(data, func1, func2, /, *funcs):
    def apply(arg, func):
        return func(arg)
    return reduce(apply, (func1, func2, *funcs), data)

# Example usage
pipeline(range(100),
    lambda x: map(lambda n: n * 3, x),
    lambda y: filter(lambda m: m % 2 == 0, y),
    tuple,
    print)

It's pretty ugly in Python, but I think with some syntax sugar (extension methods and Scala lambda placeholders), it'll look really nice:

extension AnyType:
    fn pipeline[inferred T1: AnyType, inferred T2: Anytype, func1: fn(Self) -> T1, func2: fn(T1) -> T2, /, *funcs: ??]() -> ??:
        # Similar to Python

# Same Example
range(100)
    .pipeline[
        _.map(_ * 3).filter(_ % 2 == 0),
        tuple,
        print,
    ]()

Assuming that not all functions/constructors will be callable as methods (here I assumed that map and filter will be while tuple and print will not), pipeline gives programmers the power of the |> operator with even less boilerplate (you don't have to type |> on every line).

The problem is, again, how do I annotate this function to be type-safe? Using constrained and reflection, I can ensure that the return type of the previous function in the pipeline is the same as the input argument type of the next, but how do I specify the return type of pipeline? It depends on whether funcs is empty, and again we run into the problem of needing to infer something present in a heterogeneous collection.

P.S. I'm not the first one to want this in Python or the first one to implement it:

• pipe from functoolz
• Python as functional programming language
• Chain like Ruby, part 2
• Apply operator

P.P.S. I don't want to resort to specifying the return types of my functions as AnyType if there is a reasonable solution to be found here, even though doing this would make the compiler accept my program.

[soraros]

I think this proposal doesn't concern inferring the return type much at all. There is no way to write a generic last_element on Tuples even with explicit parameter. Mojo requires you to indicate anyways.

[Brian-M-J]

I think this proposal doesn't concern inferring the return type much at all.

In the first example, dt is inferred from a parameter and then used in the return type. I was thinking of something like that:

fn scalar_func[inferred dt: DType, x: Scalar[dt]]() -> Scalar[dt]:

[soraros]

I still don't quite understand your point.
Type of the value you pass in as arguments are inferred separately, it's just that unification requires dt == x.type for a type correct call to scalar_func, and inferred informs unification to not follow the left-to-right order thus simplifying the call site. I guess one way to understand inferred is: if a function is not type-able without it, it's not type-able with it.
The problem you pose most likely needs something like variadic generics, which is quite orthogonal to this proposal. Maybe someday we have

fn last_element[T: AnyType, *Ts: *AnyType, x: Tuple[*Ts, T]() -> T: ...

Then I would agree it would be nice to also make T and Ts always inferred.

[soraros]

Are inferred only parameters unordered? How do they interact with overload resolution? Are the following considered redefinitions (I think, yes)?

fn f[inferred A: T, inferred B: S, a: A, b: B](): ...
fn f[inferred B: S, inferred A: T, a: A, b: B](): ...

[Mogball]

This is a pretty good point. This could either be considered a redefinition or always be ambiguous at callsites. I think it's better QoI to consider this as a redefinition in the same way we disallowed overloading based on return types, which implies the two functions have the same canonical type. I will add something about this in the proposal. Thanks for bringing this up!

[soraros]

This is a really nice feature to have (I want it), but will make the uninferrable part more difficult, right (comparing unordered set of parameters compared up to alpha equivalence)?
Also, can we also have inferred only parameters that only depend on other parameter (for I don't know how exactly unification works in Mojo)? I think that together with unorderedness can further confuse overload resolution.

[soraros]

Can/should we have a method to specify them explicitly? It would still be useful to sometimes specialise the generic functions to a certain set of fixed parameters.

Syntax wise, we could write f[.dt=DType.float64, Float64()](). The same syntax could be employed for inferred parameters as well, if it is not considered overly clever. Instead of a keyboard inferred, we simply write .name (inspired by Agda).

[Mogball]

Can/should we have a method to specify them explicitly?

One of the intentions of these kinds of parameters is that they are always inferred and users should not be able to specify them. This is intentional to improve the use of the API: infer-only parameters prevent users from accidentally specifying a parameter value that disagrees with another dependent parameter they provided.

[soraros]

infer-only parameters prevent users from accidentally specifying a parameter value that disagrees with another dependent parameter they provided.

This part is understood by most, I think. I just want to say that specialisation are useful in the same way: having the compiler warn about dependent parameter having the wrong type. Also, I think there are some (current?) restrictions on passing generic functions to higher order functions, manual parameter passing can at least side step that.

[soraros]

How does it interplay with automatic parameterisation?

It seems we have to choose between simplifying the definition or the call site:

fn f(s: SIMD, ...) -> ...
# VS
fn f[inferred dt: DType, inferred w: Int, ...](s: SIMD[dt, w], ...) -> ...

So thinking out loud, maybe also: fn f(s: inferred SIMD, ...) -> ...?

[Mogball]

I didn't mention autoparameterization in the proposal, but fn f(s: SIMD, ...) today already behaves like inferred parameters, in the sense that we forbid the explicit specification of the parameters for s. In fact, what you wrote are intended to be equivalent.

[nmsmith]

we forbid the explicit specification of the parameters for s

This isn't true in Mojo 0.7. Providing the auto-parameters at the call site works fine, and Intellisense shows a bunch of compiler-generated parameter names (x0, x1...).

Perhaps this has been changed in the master branch?

[soraros]

I didn't mention autoparameterization in the proposal, but fn f(s: SIMD, ...) today already behaves like inferred parameters

I'm against (-0.7) this if there is no way to specify inferred only parameter manually.

[soraros]

Should Mojo warn about uninferrable inferred parameter (e.g. free parameter that's never depend upon)? If so, when does that happen (definition site vs call site)?

[Mogball]

Yes, and it's probably better to do this at the definition site. The only problem is that definition site detection can only certainly detect the inability to infer an infer-only parameter if it is unused in any other parameter, but it would not be able to detect something like

fn foo[inferred x: Int](s: T[some_complex_expression(x)]):

So it could be considered more consistent to just always error at the callsite. I still think we should error at the definition site.

[soraros]

Hmm, shouldn't we ban inferred from some_complex_expression (function) altogether?
What about when some_complex_expression is a complex type constructor (e.g. variadic Variant) unification can kinda deal with?

[nmsmith]

I have a counter-proposal which I think is compelling. I'll post it tomorrow.

[nmsmith]

Okay, here's my counter-proposal.

Problem statement

As I understand it, the problem to be solved is that one wants to be able to declare a parameter (e.g. a: A) whose value appears in the type annotation of one or more subsequent parameters (e.g. b: F[a]), without requiring/allowing the former parameter to be explicitly provided at call sites.

The solution proposed by @Mogball

The proposed solution is to introduce a keyword inferred, which can be used to annotate a parameter. Callers must "skip over" inferred parameters when providing parameter values.

The main issue I have with this proposed language feature is that its utility seems quite narrow. I would suspect that ≥99% of Mojo function signatures won't benefit from this feature—except within applications/libraries that use metaprogramming extensively.

I suspect we all agree that language features that have broad utility are much more easily justified than those that are useful only rarely. In my counter-proposal below, I propose a pair of widely-applicable language features (syntactic sugars) that can subsume inferred. These features might eventually be added to Mojo anyway, so their ability to subsume inferred is a happy coincidence.

I have a few other concerns with inferred as well:

• Loosely speaking, inferred parameters would be "fake" parameters—they show up in the parameter list, but you can't explicitly give them a value. This seems a bit strange.
• The keyword inferred is potentially misleading, because the purpose of this feature is not to introduce parameter inference. Instead, its purpose is to allow the declaration of parameters that are skipped over at call sites. (I can foresee confused learners annotating every type parameter with inferred by default, with their rationale being "when I call a function, I don't want to provide these parameters, I want them to be inferred.")

My counter-proposal

I propose two syntactic sugars:

• The ability to provide an alias for a type annotation, using Python's existing as keyword.
• Adopting a generalization of Swift's some syntax, for declaring that a value appearing within a type-expression is one of:
  • An inferred type that conforms to a given trait.
  • An inferred value that belongs to a given type.

These features can be individually motivated, and they work well together.

Motivating as syntax

I propose that as be permitted in type annotations, as follows:

fn foo(items: DynamicVector[Optional[Int32]] as Vector) -> Vector:
    var x: Vector = items

The semantics are the same as the other uses of as in Python: Vector is an alias of the type of items, and it can be used anywhere within the function body.

This syntax really shines when combined with auto-parameterization. It allows a parametric type whose parameters have not been explicitly bound to be given a name that can be used to refer to it later. For example, here is a function that works over SIMD vectors of any length:

fn add(vector: SIMD[DType.float32] as FloatVector, scalar: Float32) -> FloatVector:
    return vector + scalar

IMO this is much more readable than the explicitly-parameterized version of this function:

fn add[length: Int](vector: SIMD[DType.float32, length], scalar: Float32) -> SIMD[DType.float32, length]:
    return vector + scalar

And I'd say it's also more readable than the following signature:

fn add(vector: SIMD[DType.float32], scalar: Float32) -> SIMD[DType.float32, vector.size]:
    return vector + scalar

This syntax works equally well in a nested position:

fn foo(items: List[SIMD[DType.float32] as FloatVector]) -> FloatVector: ...

It's also worth noting that top-level alias declarations do not have the same expressive capability as the syntax being proposed here. as syntax declares an alias for the concrete type of one particular argument or parameter. The following example demonstrates this:

fn foo(x: DynamicVector as X, y: DynamicVector as Y):
    x = y
    # ^ Error: type Y cannot be implicitly converted to X.

Motivating some syntax

It's often the case that a parameter is only used within a single argument's type. In such cases, declaring the parameter separately from the type can result in a type signature that is difficult to read. For example:

# Below, I am using a hypothetical `Collection` trait.
fn foo[C1: Collection[Int], C2: Collection[Int]](c1: C1, c2: C2):

Swift and Rust introduced the keywords some and impl (respectively) to improve the readability of such signatures:

fn foo(c1: some Collection[Int], c2: some Collection[Int]):

This syntax can also be used in nested positions:

fn foo(items: List[some Copyable]):

This syntax combines well with the as syntax that I presented earlier:

fn foo(items: List[some Copyable as T]) -> T:

The above signature would be equivalent to:

fn foo[T: Copyable](items: List[T]) -> T:

In situations where a parameter is used many times throughout a signature, this traditional syntax would potentially be more readable than some _ as _ syntax. However, the latter syntax leads to more readable function signatures in many situations:

fn largest(x: some Numeric as X, y: some Numeric as Y) -> Variant[X, Y]:

Finally, this syntax is applicable to object-parameters, not just type-parameters:

fn foo(x: SIMD[DType.Float32, some Int as size]):
    print(size)

How some and as syntax can obviate inferred

I am now ready to present my counter-proposal. The inferred proposal presented the following examples:

fn higher_order_func[inferred dt: DType, unary: fn(Scalar[dt]) -> Scalar[dt]](): pass

fn scalar_param[inferred dt: DType, x: Scalar[dt]](): pass

We can perform a direct (but naïve) translation to some _ as _ syntax as follows:

fn higher_order_func[unary: fn(Scalar[some DType as dt]) -> Scalar[dt]](): pass

fn scalar_param[x: Scalar[some DType as dt]](): pass

The translation rule is as follows: the first use of an inferred parameter in the function signature is replaced with a some _ as _ declaration. This demonstrates that some _ as _ is at least as expressive as inferred.

However these particular examples can be written much more cleanly using just as:

fn higher_order_func[unary: fn(Scalar as S) -> S](): pass

fn scalar_param[x: Scalar as S](): pass

These signatures are much more succinct than the signatures based on inferred. Going further, if Mojo were to support auto-parameterization of parameter types, the latter signature could be written even more succinctly:

fn scalar_param[x: Scalar](): pass

Benefits of this design

The main benefits of this alternative design would be:

• some and as have much broader utility than inferred.
• some syntax puts inferred parameters inline in type annotations, whereas inferred puts inferred parameters in the parameter list. The latter syntax feels a bit inharmonious, given that the caller is not able to directly assign a value to those parameters.

It would probably be a bad idea for Mojo to support both some and inferred. If Mojo had both keywords, there would be far too many ways to express the same function signature.

This concludes my counter-proposal. 🙂

[nmsmith]

Actually, you know what? It is possible for some to serve as a canonical form for inferred parameters. Replace the word some with inferred in every one of the examples I presented.

Given the following function signature:
fn foo(x: SIMD)

Instead of proposing that it desugars to:
fn foo[inferred a: DType, inferred b: Int](x: SIMD[a, b])

One could propose that it desugars to:
fn foo(x: SIMD[inferred DType, inferred Int])

Which is just some syntax with the keyword changed.

So my counter-proposal is just a different (isomorphic) syntax for the feature that @Mogball is proposing. (Plus an as keyword, which has broader utility.)

[Mogball]

inferred parameters seem very appropriate for Mojo's IR, just as SSA is. But programmers don't write their code in SSA

Mojo is one part "syntax sugar for MLIR", so it is consistent with the design principles of the language to expose something like this.

I don't necessarily think inferred and some are isomorphic. One is a passing kind and the other is some kind of unbound type expression thing. The problem with some is actually a problem auto parameterization has today: what does a partially bound type mean in other contexts besides a function argument type? Right now it errors, but with more "friendly" syntax like some and as, coupled with Mojo being context insensitive, means

struct A:
    var thing: some Scalar as A

var y: some Dict = ...

Have to broadly make sense as well. I think we can make these things sensible (and actually this will all help with lifetime parameters too), but that has to come first before any syntax sugar. As far as syntax sugar goes, pattern matching is quite far away.

A separate gripe I have with some is that it risks hiding a cost model from the user:

fn generic(x: some List)

Is x an existential or a parameterized type? If we say any means existential and some means the other, I imagine this can be very confusing.

[nmsmith]

What does a partially bound type mean in other contexts besides a function argument type?

Why not just make this an error? What other meaning would you give to such type annotations? (I expect that it wouldn't declare something dynamically-typed—that would be far too subtle.)

Is x an existential or a parameterized type? If we say any means existential and some means the other, I imagine this can be very confusing.

This is a problem in Swift, but I don't think Mojo wants or needs a keyword that is equivalent to any. Ideally, objects that carry type information at runtime won't need to be declared using a magical keyword. Instead of the Swift-style syntax fn foo(x: List[any Copyable & Stringable]), I would hope that this can be expressed using an ordinary struct parameterized by a list of traits: fn foo(x: List[Object[Copyable, Stringable]]). I've discussed such a design here.

More generally, I'm not necessarily advocating for the keyword some. Potentially a more illuminating word can be found, e.g. inferred, or param.

[Mogball]

What other meaning would you give to such type annotations?

The parameter is inferred from the variable initializer expression. Less clear to me what it would mean in a struct field but maybe it gets hoisted onto the struct itself?

[Mogball]

I would hope that this can be expressed using an ordinary struct parameterized by a list of traits

Yeah that's pretty similar to what I've been thinking about. I'll go comment there.

[nmsmith]

Curly braces are another syntax worth considering:

fn foo{dt: DType}[x: Scalar[dt], y: Scalar[dt]]()

This syntax could also be used to enumerate the variables that a closure captures by-reference, since captured variables are conceptually similar to inferred arguments. (In both cases, the variable doesn't need to be provided at the call site.)

[nmsmith]

It's also worth considering whether the proposed syntax extends cleanly to inferred arguments, on the assumption that Mojo will support them at some point (e.g. if/when types can be passed around at runtime):

fn foo(inferred T: AnyType, x: T):

Combining this syntax with a self argument seems a bit awkward (assuming that inferred arguments must be listed first):

struct Thing:
    fn foo(inferred T: AnyType, self, x: T):

But I suppose there's no reason for the proposal to be blocked on this. We'd just need to be willing to change the syntax in the future, as necessary.

[nmsmith]

I've thought of another kind of "inferred thing" that Mojo might eventually have: trait instances. It might be good to have this use-case in the back of our minds when considering the design of inferred parameters.

(Apologies for the length of this post. I expected this to be a short comment. 😅)

What constitutes a "good" semantics for traits is incredibly subtle. Rust and Swift model traits/protocols in a somewhat flawed/hyper-restrictive way. To guarantee soundness, both languages require every type to implement a trait at most once within an application plus all of its dependencies.

• Rust enforces this by preventing you from implementing a trait defined in library X upon a struct defined in library Y.
• Swift doesn't enforce this. It just warns you about it. (And if you violate the rule, I think the outcome is essentially undefined.)

The purpose of these restrictions is avoid various bizarre and subtle bugs wherein a value is operated on using conformance A in one context, and conformance B in another context, and those conformances conflict. A common example is a hashed data structure, e.g. struct HashSet[Element: Hashable]. If I construct a HashSet[Foo] in one context, and then pass it into another context where Foo's implementation of Hashable is different, then queries on the hash set would return garbage results.

IMO, a promising solution to this problem would be to model implementations of traits as values, and have them appear as inferred struct parameters:

struct HashSet[Element: AnyType, inferred h: Hashable[Element]]

This statically enforces that a hash set can only use a single trait implementation over its lifetime. This also means that the trait implementation will be propagated throughout all functions and variables that operate on hash sets derived from the original set.

Some notes:

• We have given the Hashable trait a parameter: namely the type that conforms to the trait. This implies that traits are declared with an explicit Self parameter, which I think is a good idea irrespective of everything else, because it means that Self doesn't need to be a magical keyword in trait definitions.
• Hashable[T] is understood as a type, and h is understood as an instance of that type.
• This would be the desugared syntax. I wouldn't expect people to express type signatures like this.
• AnyType must now be understood as something other than a trait bound. (Otherwise, we'd get stuck in an infinite loop of desugaring.) It should potentially just be a keyword.
• There are a lot of design details missing, e.g. how would the compiler know which trait instance to pass as a parameter. But that is irrelevant, because this post is not meant to be a design proposal for traits. 🙂

This approach isn't novel. Scala does something similar.

Long story short: the above example demonstrates a potential use of inferred to model implicitly-passed trait instances. (Contingent on a suitable semantics for implicitly passing trait instances.)

Note: to respect left-to-right reading, the inferred parameter needs to appear at the end, which is not permitted under the OP's proposal.

This is all just "future work" of course. There's no reason to block an initial implementation of inferred parameters on a future design for traits.

[nmsmith]

I'm not sure what you're dissatisfied with. If you consider Mojo's current syntax for trait bounds to be sugar for the syntax you gave, then nothing would change syntactically:

fn[T: Hashable](s: HashSet[T]) -> Optional[T]

This signature could be understood as desugaring to your one. In today's Mojo, if you remove the trait bound, you get a compile error.

[soraros]

Oh, yea. I was wrong. It seems we will need proper handling of partial type constructors after all.

[nmsmith]

Small update: after thinking about the topic for the last two days, I'm now starting to doubt that propagating trait instances using some form of "inferred parameters" or "implicits" would be wise. Several languages (Scala, Adga, Idris...) have tried this, and the usability is pretty meh. There's too much "spooky action at a distance".

Despite this, we still need to solve "the HashSet problem". In particular:

• We want people to be able to write HashSet[String], and have this be a fully-bound type.
• Every value of type HashSet[T] must be locked to a particular Hashable instance.
• We want users to be able to define alternative trait instances for library types. For example, a different (perhaps faster or more secure) Hashable instance for String.

If we discard implicits, the only remaining option I can think of that achieves this outcome would be for types to carry trait instances with them. For example, every type T for which HashSet[T] type-checks must carry a Hashable instance with it.

Update: As mentioned at the end of my next post, I've since realized that such a design couldn't possibly work.

This doesn't necessarily imply that each struct can only implement a trait once. The trick would be for the concept of "type" to mean not just a struct (or a class), but rather: a value that consists of a struct and a set of trait instances (and also, extensions). For example, the identifier Int wouldn't refer to a struct. Instead, it would refer to some other value, and in turn, that value refers to the struct that defines the Int, but also to a set of trait instances, e.g. a Stringable instance. This could be a promising direction to explore.

Any further discussion about such an approach should take place in a different thread, because it would be unrelated to the current thread's topic.

In short: I don't think the proposed inferred feature will have any interaction with traits. Carry on. 🙂

[soraros]

You lost me half way. It looks like you missed some known results on the whole implicit/ad-hoc polymorphism business; the literature covering it is thick, and I doubt any obvious solution and their derivation which no one has written a paper about still exists 🙃.

Several languages (Scala, Adga, Idris...) have tried this, and the usability is pretty meh. There's too much "spooky action at a distance".

Does this come from your experience or your speculation/imagination? Proof assistant (Agda, Coq, etc.) tend to use typeclasses much more intensely, and they see to work just fine (my experience). Also, "propagating trait instances" is what Haskell does, making/calling them "instance argument" in Agda is just a formal way to express that idea.

HashSet[T] is just HashSet[T, theUniqueHashableInt: Hashable[T]], where TheUniqueHashableInt is a "trait instance" (just a dependent record, nothing special), it is fully bound. Having proof search help you find this instance doesn't mean the type itself is not full bound. When we provide our own hashable, the type becomes HashSet[T, myInstance]. If we (should) allow instance resolution to also find MyInstance is a separate issue, we could go the ML module way.

The detail of how your type is group with its TC instances hardly matters. Important question is this: is your Int with default hashable a different type from Int without?

• If the answer is yes, it's equivalent to the Haskell solution, wrap the type so you can attach a different hashable. Or related, it's similar to the basic OO idea.
• If the answer is no, the difference much still be reflected somewhere else, like in Hash[T, ins1] vs Hash[T, ins2].

I don't think the proposed inferred feature will have any interaction with traits.

"how TC works example above mentioned the two notions of implicit arguments ({...}and{{...}}`), and they are known to be related but different features.

• inferred proposed in the rfc is about solving the unification problem that can only have one solution, so we might as well leave it to the unification engine
• inferred instance is about putting a solution (a instance) in the environment so TC resolution can find it. Unification still relevant because instances are "keyed" by type. Uniqueness guaranteed if global coherence.
  They are/can be implicit for different reasons, and I fail to see how this is new.

FYI, the way how Rust trait system works (and how Mojo trait system aspire to work?), might be closer to canonical structure. I'm not entirely sure if this categorisation is accurate, but it is also mentioned above ("packed vs unpacked").

[nmsmith]

I doubt any obvious solution still exists 🙃.

I disagree. For one thing, the vast majority of literature on type classes assumes you are working with a functional language based on algebraic data types and free functions, rather than classes/structs/OOP. That changes a ton of things. I agree that if your language is a Haskell clone, then all of the low-hanging fruit has probably been picked.

Important question is this: is your Int with default hashable a different type from Int without?

The answer is neither "yes" nor "no". As instances of a composite (meta)type, the two types would have distinct values. However, the types would hold a reference to the same Int struct, so although the types would be different, they would be compatible in some sense.

The research question is how/whether it is possible to formalize such a notion of compatibility between types that refer to the same struct, but to different trait instances.

Update: I've since realized that having a type carry around trait instances violates the open-closed principle, i.e. it would prevent trait instances (and other extensions) that your app defines from being callable on values returned from a library. So, I'm reverting to my previous hypothesis: I think trait instance resolution (and trait/extension method resolution) needs to be lexical, and combined with some flavor of inferred parameters. But as soraros pointed out, this is probably not the same thing as the inferred concept that OP has proposed.

[nmsmith]

I've come up with another potential alternative to inferred syntax. I won't write it up just yet, because I have other work to do, but @Mogball if you let me know when your proposal is going to be worked on, I'll write up my alternative.

[mikowals]

If you are referring to the main topic here of inferred parameters this has been implemented but not yet made public as of a few days ago.

[nmsmith]

It's not clear from that issue what has actually been implemented. There are several improvements to parameters that have been in the planning stage for a while. Are you sure that it is OP's proposal?

[mikowals]

Sure is a strong word but I would be 97% confident there is a feature implemented that allows parameters to be inferred from other parameters. Evidence supporting this view:

• The OP here links to that specific issue
• That specific issue has been closed with a comment saying it is completed

I would only be slightly lower that it has been implemented with the inferred keyword specifically as described in this proposal. It is the only proposal so to implement it a different way without updating the proposal would be surprising. They didn't need to write the proposal but I expect they did it because they actually needed to think through the solution. Once that was done it may as well be shared.

The main reason to think it is not done or something else is done is because the comments about completion are brief, lack specifics, and don't link back to this discussion. But familiarity with the issue and knowing it has been discussed extensively elsewhere could also explain that.

We will know specifics within a couple nightly versions I expect. And most likely the next one I would guess since keeping changes to main out of the nightly is probably cumbersome.

[mikowals]

I was apparently wrong and the issue is reopened. Closed by mistake.