[swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

[Andrew Bennett]

Excellent point Brent. I was considering that this would have to be an
exact match, I hadn't considered the need for an (x: Y) syntax.

This probably should be considered in a future proposal though. The future
proposal may make sense to be after existential types are explored, so that
common sub-types can be matched where there are associated-type
requirements.

I'm a +1 on this proposal, I'm not sure if I need to say so, see the
proposal for my analysis.

Thanks everyone for your comments so far!
Andrew Bennett


On Thu, Mar 17, 2016 at 1:36 PM, Jordan Rose via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Mar 16, 2016, at 18:10 , Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >>      • What is your evaluation of the proposal?
> >
> > Good stuff.
> >
> > How exact does the type match have to be? Can they be two subclasses of
> a different superclass? Can they conform to common protocols? Can they
> conform to no common protocols and just be `AnyObject` or `Any`?
> >
> > Is there a way to specify the type, either to get an exact match or just
> to ask or a supertype? If you do that, does it have to be specified on
> both, or only one? Something like:
> >
> >       case let .Case1(x: SignedIntegerType, 2), let .Case2(2, x):
>
> In GregT's current implementation, the types have to be an exact match.
> You can use the existing "as Foo" constraint to specify a type, but it must
> be specified everywhere that that wouldn't be the inferred type. (See my
> earlier message to Andrii C:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012779.html)
> Note that that also isn't "as!"; if used with a subtype instead of a
> supertype, it imposes (and has always imposed) an additional constraint on
> the match.
>
> Jordan
> _______________________________________________
> 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/20160318/caadab0c/attachment.html>