[swift-evolution] guard let x = x

[Julian Dunskus]

I hate keeping this going even though we decided to put it off for phase 2, but I just had to add something:
Why not just put @unwrappable on the actual unwrappable case instead of the enum itself? You could even make multiple cases @unwrappable to specify (given that they have the same type) that any of them could be unwrapped.

–Julian Dunskus

> On 31 Oct 2016, at 14:18, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 29 Oct 2016, at 02:10, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Sounds good to me. Leaving the gist in its updated state (a little further from the last time) for the record.
> 
> I like the first part, even though I disagree that `if let foo = foo` conflicts with DRY principles. However, I think you should drop the part about unwrapping enums for now. That looks like a whole can of worms with a zillion edge cases and could be dangerous in the wrong hands:
> 
> @unwrappable(type: String)
> public enum Result
> {
>    case success(String) // String is the data requested
>    case error(String) // String is an error message
> }
> 
> func getTheResult() -> Result { … }
> ….
> 
> if unwrap getTheResult() 
> {
>    // Here we put the code for the success case - or do we?
> }
> 
> In the above, the code that uses unwrap would be broken simply by reordering the cases in the enum declaration and not in a good way. There would be no compilation or runtime error, an error message would simply be treated as normal data. 
> 
> Having code depend on the order of something somewhere else - not necessarily even in the same module doesn’t seem very Swifty to me. 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution