That’s an interesting proposal. Here’s a link for reference:  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027287.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027287.html>

The one thing is the proposed syntax doesn’t handle enum cases without 
payloads. I think that could be handled by an optional Void, so this comment in 
the original proposal:

> Only enum cases with a payload can be used with this syntax (it would make no 
> sens for cases without a payload).

Would be changed to allow for empty payloads turning into Void?. For example:

> enum Result {
>     case success(Int)
>     case failure
> }
> 
> let r: Result = foo()
> 
> let x: Int? = r.success
> let y: Void? = r.failure
> 
> assert(r.success == Optional(42))
> assert(r.failure == nil)
I think it’s a reasonable compromise, though I still think it’s a bit awkward 
for the common case. Looks like this is being postponed for now, so we’ll have 
to live with the alternatives.

Andy


> On Jan 18, 2017, at 12:20 AM, Anton Zhilin <[email protected]> wrote:
> 
> AFAICS, Andy needs not default implementations of Equatable, but 
> cases-as-optional-properties—this topic has also been discussed on the list.
> 
> enum Result {
>     case success(Int)
>     case failure(String)
> }
> 
> let r: Result = foo()
> 
> let x: Int? = r.success
> let y: String? = r.failure
> 
> assert(r.success == Optional(42))
> assert(r.failure == nil)

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to