[swift-evolution] guard let x = x

[Xiaodi Wu]

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> wrote:

> On Oct 28, 2016, at 6:22 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Oct 28, 2016, at 5:55 PM, Kevin Nattinger <swift at nattinger.net> wrote:
>
> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Oct 28, 2016, at 5:00 PM, Huon Wilson <huon at apple.com> wrote:
>
> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution <
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161029/6fd865ed/attachment.html>