# 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.