I’m tempted to recuse myself as well on the technical merits of this proposal. As others might already expect, I am concerned about this breaking existing code. Do we have a rough estimate how much this will break?
It also surfaces a topic we discussed just a short while ago. We have a feature in a stable compiler release, which we consider experimental, and thus reserve the right to break? I find this concept still fundamentally flawed. Anything that is part of stable compiler releases has to be considered stable by extension and thus needs to be treated with utmost care.
I can see and fully support the wish to have a language reactor where things can be experimented with. But if we have this in our stable releases, it needs to be guarded in a way that users of those features have to actively opt in to it. I have people seen adopting this feature already, and I do not believe all of them are aware that this is a bleeding edge feature that can break without notice at any point in time.
As there is supposedly a backwards compatible implementation for this, I’d like to ask for this to be considered in two steps:
- backwards compatible change first.
- deprecation and change of syntax second.
Yes, this will be more work on behalf of the implementors. The burden of change is on the implementors, we can’t expect our users to cover the costs.
For the second part, we should also have a thorough justification for the need to break.
I’ll leave this with two links:
Simon Marlow’s recent comment:
Dimitriis Tweet contrasting OCaml to Haskell:
Best
Moritz