[swift-evolution] guard let x = x

[Jay Abbott]

@unwrappable(type: Int)
> public enum Count {
>     case none // not unwrappable
>     case many // not unwrappable
>     case some(Int)
>     case owed(Int)
>     case something(String) // not unwrappable
>     case multiple(Int, Int) // not unwrappable
> }
>
> Instead of requiring the @unwrappable attribute, why not have unwrap work
normally when the type can be inferred, or require hints when it can’t:

// For an optional (or any other enum with only one wrapped type)
guard unwrap x else { return }// For an enum of type Count as defined above
guard unwrap myCount else { return } // compiler error - type can't be
determined
guard unwrap(myCount: Int) else { return } // Success for 'some' or
'owed' (implicit shadowing)
guard unwrap(let someOrOwed: Int) myCount else { return } // Success
for 'some' or 'owed' (no shadowing)
guard unwrap(let x: Int, let y: Int) myCount else { return } //
Success for 'multiple' (no shadowing)

Notes:

   - unwrap x is equivalent to unwrap(x: T) where there is a single
   unambiguous type.
   - The let keyword probably could be implicit for the non-shadowing
   forms, like it is for the shadowing form, but makes it clear what’s going
   on.
   - unwrap fails for none or many from the Count type, just as it does for
   none from Optional
   - I *think* that this assumes Swift is not allowed to try to infer the
   most restrictive type for reference types. Haven’t really thought about
   this much.

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161030/9c050ec3/attachment.html>