---
# System prepended metadata

title: Notes on Positional Associated Types (PAT) conversation

---

# Notes on Positional Associated Types (PAT) conversation

Lang Team Proposal: https://github.com/rust-lang/lang-team/issues/126

Zulip stream: https://rust-lang.zulipchat.com/#narrow/stream/243200-t-lang.2Fmajor-changes/topic/Positional.20Associated.20Types.20lang-team.23126/near/261202116

Lang Team Meeting: [2021-11-16][] 

[2021-11-16]: https://hackmd.io/sr9RfdyOSS6HHevYsaxh1Q?view#%E2%80%9CPositional-Associated-Types%E2%80%9D-lang-team126

## Notes from [2021-11-16][]
 * forbids future evolution of a type parameter with a default
 	* editorial: "forbid" is strong term; is it true
	* ah, this is summarizing the first bullet from zulip below
 * can this lead to user confusion?
 	* how does one learn difference between generics and associated types?
 	* (It claims it is trying to *cope* with user confusion
 * "you won't know how to name the type" (?)
 * How important are names?
 	* what is importance to readers of code vs writers of code?
 	* for things like` Iterator` and `Future`, reasonable to infer that seeing names does not help you in reading the code
 * is the name itself important, or is the important thing to have some marker distinguishing between a type parameter vs an associated type? (Consider syntaxes like `Iterator<=u32>`, `Iterator -> u32`, or `Iterator -> u32`).
 	* Would a separate syntax be worth its weight?
* the proposal claims this change will improve Rust's learning curve; but that argument needs substantiation.
	* One should not assume conflating two different things, or hiding the difference, improves learning curves
	* On the other hand, forcing people to pay attention to a difference like this is not necessarily a win either.
* In some future scenarios, the distinction between generics and associated types may become important in new ways.

## Notes from Zulip thread

 * having PAT on a trait implies it is breaking change to ever add a defaulted generic param.
	* thus PAT's are opt-in
	* but the point is: huge back compat promise compared to (small?) benefit
	* counterpoint: traits like Iterator are very unlikely to ever add additional generics
 * alternative solution: trait aliases, e.g. `trait Fut<T> = Future<Output=T>;`
 	* but this introduces a layer of indirection: have to look up `Fut` to find out what it denotes.
* It is form of "magic overloading"
	* If the line between a generic parameter and an associated type is blurry for beginners, then removing the syntactic requirements that tell these two things apart will not help
	* "Does SomeTrait<T> mean associated type or generic?" is a question I don't look forward to answering / explaining.
 * alternative solution: output type in input position of trait definition
	```rust
    trait Iterator<I == Self::Item> {
	    // `I` is generic parameter, but constrained to be equal to the associated type.
        type Item; // assoc type
    }
	```
	
 * One key detail about an MCP: this is a proposal to solve a problem, not necessarily a commitment to a specific solution; So the syntax could change.