# Formally revoking SE-0042 **URL:** \ **Category:** Discussion\ **Created:** [August 23, 2019, 3:40pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174 "2019-08-23T15:40:49Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [August 23, 2019, 3:40pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/1 "2019-08-23T15:40:50Z")
[SE-0042](https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md) was formally [accepted](https://forums.swift.org/t/accepted-se-0042-flattening-the-function-type-of-unapplied-method-references/1926) 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. In [April of 2018](https://forums.swift.org/t/introduce-flattened-unapplied-method-references-se-0042-revisited/11765/17), Joe Groff wrote: > [@](#): > > We have strict source compatibility constraints now, and since SE-42 was not implemented as proposed originally and the Swift 2 behavior was never removed, we can’t accept the proposal as is anymore. I would support a re-pitched proposal to provide the behavior SE-42 proposed with different syntax, such as the keypath-style `\Type.method` syntax. We could then potentially deprecate the old syntax and behavior. And [in October](https://forums.swift.org/t/allow-key-path-literal-syntax-in-expressions-expecting-function-type/16453/15) of that same year, Matthew Johnson added > [@](#): > > It's also worth mentioning that the plan at this point is to revisit SE-0042 and introduce syntax similar to key paths for unbound method references (rather than incur the source breakage that would be necessary to implement SE-0042 as it was accepted). So consistent syntax is on the horizon, we're just not there yet. Yet, the proposal is still listed as "accepted", and [SR-1051](https://bugs.swift.org/browse/SR-1051) is still marked "unresolved" (and even with "medium" priority). The [Swift Evolution Status page](https://apple.github.io/swift-evolution/) 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. ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [August 23, 2019, 3:43pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/2 "2019-08-23T15:43:04Z")
+1 for the key-path syntax solution. ---
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [August 23, 2019, 3:46pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/3 "2019-08-23T15:46:55Z")
> [@DevAndArtist](#): > > +1 for the key-path syntax solution. 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. ---
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [August 23, 2019, 4:52pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/4 "2019-08-23T16:52:25Z")
@Joe_Groff? ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [August 23, 2019, 5:09pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/5 "2019-08-23T17:09:13Z")
Yes, it should be revoked at this point. ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [August 24, 2019, 1:45am UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/6 "2019-08-24T01:45:38Z")
I have [updated the proposal](https://github.com/apple/swift-evolution/commit/87a6d06582b2779fc3dbac4707798788d742ea82) to represent its actual status. ---
**Author:** ![waterform](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/waterform/32/8878_2.png) [@waterform](https://forums.swift.org/u/waterform)\ **Post date:** [September 2, 2019, 1:58pm UTC](https://forums.swift.org/t/formally-revoking-se-0042/28174/7 "2019-09-02T13:58:28Z")
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](https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md) (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.