SE-0042 was formally accepted more than three years ago. However, since the proposal was accepted before having a working implementation was a requirement, and the change would be source breaking, and also require massive rewrites of the compiler; it is now clear that this proposal will never actually be implemented. It has been obvious for a long time.
And in October of that same year, Matthew Johnson added
Yet, the proposal is still listed as "accepted", and SR-1051 is still marked "unresolved" (and even with "medium" priority). The Swift Evolution Status page gives the impression that it will actually be implemented in some future version of Swift.
Is is time to formally mark SE-0042 as "Revoked", SR-1051 as "won't fix"?
Does it require a formal SE proposal to revert the behaviour, and present a null-implementation? Currently, the de-facto direction of Swift and its formally accepted direction, are out of sync.
Sure. But I guess that can be discussed independently.
Is is a requirement that the rationale of SE-42 be solved in an alternative way, for SE-42 to be formally revoked?
I think even the status quo of not having the key path syntax and keeping the curried methods, is still preferable to having de-facto "dead" proposal listed as accepted. It's akin to "dead letter" legislature.
I hope there will be a solution to this problem in the future. It would be sad if just because of strict source compatibility constraints or that it would be too much compiler changes this would be ignored forever, even if there is a good solution at hand. The best thing for me of Swift is, that there was no fear of changes, so Swift would never evolve to an always backwards compatible JavaScript (horrible inconsistencies for coders).
If there is a good reasoning against implementing flatting of unapplied methods, then do not do it, but it should be a reason that has nothing to do with how much work it would be. The amount of work and changes involved should only change the timeframe and how fast the old syntax is replaced/changed.
The posts of @Joe_Groff and Matthew Johnson do give me a good impression, that removing currying in unapplied methods is still a good idea (also my opinion), but just through a different implementation (maybe keypath-style). So if the general idea has been deferred, I am fine with that. Learning to be patient is something that fits with Apple customers .
Maybe it would be nice if such an information why it was rejected (or a link) would be visible on the evolution page/GitHub. On the other hand it was easy for me to find that post here.
This and the SE-0110 (to distinguish multiple arguments from one tuple) are my most awaited changes. And SE-0110 may also have the same problem as SE-0042. It will break source compatibility, it seems like a small change, the current syntax does work and it has minor interest. But, waiting too long can create the same problem for SE-0110 that is now apparent in SE-0042, even though it has been decided as a good solution.
.