On 18 May 2026 17:50:55 BST, Larry Garfield <[email protected]> wrote:
>Rowan's "erased user-extensible type system" is an interesting idea, and I >think it's worth exploring. But I don't think this RFC is the place for it. >This is a partially-enforced-generics proposal, so using an "ignored by the >engine" flag for its syntax would make things more confusing, not less. On the contrary, it's that partial enforcement that the idea is trying to help with. Right now, if I write "function foo(_ $x)" then no matter what type I put in place of "_", the answer to "is it enforced?" is "yes". With the current proposal, that answer might be: - Yes - No: it's an unbounded type parameter which erases to "mixed" - Partially: it's a bounded type parameter which erases to the bound; or it's a parameterised type which erases to a normal one (e.g. Box<int> to Box) - Maybe: it's a type parameter on an abstract class, and sub-classes might be monomorphized, but might be generic themselves The syntax won't give any hint which is which, and the same syntax in different places is enforced to different extents. In the current shape, I will vote No, because I think that will be horrible to work with. Shinji Igarashi suggested an "erased" keyword to leave the main syntax free for reified generics, and it got me thinking how we could generalise that to indicate the difference between "real" type declarations, and reflection-only type hints. I'm not claiming to have a ready-to-ship proposal with all the details, just looking for a compromise that would give the standardisation and reflection capabilities Seifeddine wants, but keeps it clear to users which types are actually enforced. Rowan Tommins [IMSoP]
