[swift-evolution] guard let x = x

[Erica Sadun]

Sounds good to me. Leaving the gist in its updated state (a little further from the last time) for the record.

-- E

> On Oct 28, 2016, at 7:02 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Granted that this whole topic is out of scope currently, I think the enum unwrapping facility is its own subject entirely, separable from the `if let x = x` sugar.
> 
> Approaching this issue from another perspective--namely, improving enums to better enable some use cases prompted by requests for union types--I've developed some ideas for unwrapping that I've been keeping under wraps (hehe) until the next phase of Swift evolution, and it'd be nice to have a dedicated conversation about such ideas when the time is right rather than rolling it into the topic of `if let x = x` sugaring.
> 
> On Fri, Oct 28, 2016 at 7:42 PM Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> On Oct 28, 2016, at 6:22 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On Oct 28, 2016, at 5:55 PM, Kevin Nattinger <swift at nattinger.net <mailto:swift at nattinger.net>> wrote:
> 
>>>> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>>>> On Oct 28, 2016, at 5:00 PM, Huon Wilson <huon at apple.com <mailto:huon at apple.com>> wrote:
> 
>>>>>> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>>>> How does the compiler decide whether to succeed on anycase or succeed on anothercase respectively? In general, the compiler only statically knows that first & second are of type TypeName, not anything about which case (they could be passed in as function parameters, or returned by an opaque function e.g. `let x = OtherLibrary.returnsTypeName(); guard unwrap x else { … }`), and thus the variant to unwrap has to be chosen based only on that piece of information.
>>>>> 
> 
>>>>> It seems to me that doing this either has to be restricted to enums with an “obvious” choice for unwrapping, like Optional, or rely on a sort of forward-looking type inference that Swift doesn’t currently use to deduce the unwrapped type based on how the value is used later (and I’m not sure that works in all cases, e.g. what if T == U for the TypeName example).
> 
>>>> It succeeds on any one-item case and fails on any non-item case.
> 
>>> 
>>> I think he meant this:
>>> 
>>> enum TypeName<T, U> { case anycase(T), anothercase(U) }
>>> 
>>> func foo<T, U>(instance: TypeName<T, U>) {
>>> 	guard unwrap instance else { ... }
>>> }
>>> 
>>> What type does instance have? 
> 
>> 
>> Fair enough. How about: An unwrappable enumeration must have at most one generic type so the compiler can guarantee at compile time that the type is unambiguous if the unwrapping succeeds
> 
> 
> And updated gist:
> 
> Detailed Design
> 
> The unwrap statement shadows an enumeration variable to an unwrapped version of the same type. Using unwrap is limited to enumerations that satisfy the following conditions:
> 
> An unwrappable enumeration must specify the unwrap type, probably through an @unwrappable attribute.
> Unwrapping is limited to one-item cases with that type.
> No-item or multi-item cases cannot unwrap.
> Cases using a different associated value type cannot unwrap.
> @unwrappable(type: Wrapped)
> public enum Optional<Wrapped> {
>     case none
>     case some(Wrapped)
> }
> 
> @unwrappable(type: ValueType)
> public enum Result<ValueType> {
>     case value(ValueType)
>     case error(Error)
> }
> 
> @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
> }
>  <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#impact-on-existing-code>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161028/e046285a/attachment.html>