[swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns
cacoyi at gmail.com
Fri Mar 18 06:25:51 CDT 2016
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
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!
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:
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution