Named type parameters

[kennytm]

Because Thing<X=Y> already means Thing where Self::X == Y.

(Think Box<Iterator<Item = u8>>)

[felix.s]

Being dumb: why not

let foo: HashMap<A = OtherAlloc> = …

?

I guess this could conflict with syntax for bounds on associated types?

(Which is quite unfortunate anyway; where <T as Iterator>::Item = U would be much clearer than where T: Iterator<Item=U>, even if it’s more typing.)

[leodasvacas]

Is @nikomatsakis concern regarding places without inference such as signatures or places with inference such as turbofish? Or both? In places without inference I see the issue that we currently do not allow something like HashMap<i32, i32, _, MyAlloc> but we could just allow that with _ using the default.

I don’t see the status quo as a problem, at least there is insufficient motivation for changing it at the moment. Inference and defaults can go a long way in mitigating this.

[Centril]

Yes, the problem is with associated types per @kennytm’s comment.

[Centril]

we currently do not allow something like HashMap<i32, i32, _, MyAlloc>

We don’t? Interesting, TIL…

I agree it would go some ways to making the situation more ergonomic… but what if you only want to change the allocator and let the key and the value type be inferred? Then you have to write: HashMap<_, _, _, MyAlloc> which is somewhat outrageous…

[leodasvacas]

but what if you only want to change the allocator and let the key and the value type be inferred?

The allocator value must be provided upon construction, it would be very difficult for it to go uninferred.

[Centril]

The allocator value must be provided upon construction, it would be very difficult for it to go uninferred.

Oh yes, good point; However, there may be other APIs where this is not the case.

[mikeyhew]

Because Thing<X=Y> already means Thing where Self::X == Y.

True, but couldn’t that syntax support both?

[kennytm]

No because this is legal:

trait X<A=i32> {
  type A;
}
type M = X<A=u32>; // which A are you talking about?

[mikeyhew]

If there were a way to opt into named type parameters, though, as @Centril suggested above, then the name collision could be a hard error without breaking backward compatibility.

[Centril]

If there were a way to opt into named type parameters, though, as @Centril suggested above, then the name collision could be a hard error without breaking backward compatibility.

So I’ve been thinking that you can do:

trait X<{A} = i32> { // Using the syntax {A} opts in
    type A;
}

trait M = X<{A} = u32>; // This refers to the type parameter A
trait M = X<u32>; // Same as previous.
trait M = X<{A} = u32, A = ()>; // Type param is u32 assoc type is ()
trait M = X<u32, A = ()>; // Same as previous

This makes the opting in syntax the same as the syntax for using the name of the type parameter which is always nice property to have. The brackets used in {A} are totally bikesheddable.

[mikeyhew]

To be honest, I don’t see the {TypeParam} syntax gaining traction. It’s just too weird: think of all the people learning Rust and seeing that for the first time, and finding out that syntax is only required because of some obscure backward compatibilty issue.

But doesn’t the example that @kennytm posted – the one with an associated type and type parameter with the same name – seem like an anti-pattern? If that’s the only thing keeping us from getting the syntax we want, then we should consider deprecation.

What we could do is, initially, just default to the associated type when there is a conflict, but add a warning (on the trait definition itself, and wherever Trait<A=u32> syntax is used), and at some later date, turn the trait definition warning into a hard error.

[Centril]

To be honest, I don’t see the {TypeParam} syntax gaining traction.

It’s just a placeholder/strawman syntax until we get something better =)

What we could do is, initially

We should check how often it happens that an associated item and a type param have the same name by making it an error for them to have the same name, and then see how much a problem it is with a crater run. Since an epoch is approaching, it might be prudent to do this soon-ish.

[mikeyhew]

We should check how often it happens that an associated item and a type param have the same name by making it an error for them to have the same name, and then see how much a problem it is with a crater run.

I was thinking the same thing I’ll try and open a PR with that change soon so we can do the crater run

[scottmcm]

let foo: HashMap<K, V, {A} = OtherAlloc>

I’d avoid {...} here since that’s used for const generic parameters to flip into expression mode from type mode.

[kornel]

I think that’s fine — we can define shadowing order. If you use the same name for both (which is silly and who would do that?), then you just won’t be able to use named arguments.

[nikomatsakis]

I’ve not following closely, but one thing I’d like to inject:

I don’t think we want names to automatically become part of the public API. This gives an opportunity – if type parameter names must “opt-in” to being nameable, we can check for conflicts with associated types and the like.

[Centril]

I was thinking the same thing I’ll try and open a PR with that change soon so we can do the crater run

Did your experiment yield any results?

[mikeyhew]

No, I stopped working on it after @nikomatsakis pointed out that traits would have to opt-in anyway

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.