> On Aug 24, 2016, at 9:33 PM, Xiaodi Wu <[email protected]> wrote: > > On Wed, Aug 24, 2016 at 9:25 PM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I have 3 qualms with this proposal as it stands: >> >> - type(of:) will never lie to you. >> >> The only question it won’t answer to your satisfaction is the dynamic type >> of the NSString you boxed up as an Any. >> >> - No more keywords without significant justification. >> >> I don’t buy the performance use case at all - if you were properly concerned >> about performance you would try to use as many of Swift’s static features as >> possible. >> >> - Especially no more keywords that look like they belong in Rust or PHP! >> >> There is no precedent for the spelling of these operations other than the >> suffixed punctuation. Given that they’re domain-specific, will definitely be >> hard to use (given that NSString(string: "Bar”) may not “really” given you >> an NSString yet that’s what you asked us to check for “really"), and will be >> obviated by the implementation of SE-0083, I can’t see a reason why we need >> any of this in the language proper. > > One related topic to consider is exhaustive pattern matching for classes. > Now that SE-0117 has been accepted it will be possible to do this for many > classes (I would say most if it weren’t for Objective-C classes being so > common in Swift and are imported as `open`). Supporting exhaustive pattern > matching well would require some kind of syntax for matching the runtime type > exactly. I have imagined this as being “exact match” cast operators, which > is what the `really_*` operators are. > > I don't understand. As pitched, these operators remove bridging magic, but > `Subclass really_is Superclass == true`. How would you use this for classes?
Bridging is the use case motivating the pitch. I am bringing up a related use case. The pitch does not specify `Subclass really_is Superclass == true` and I would argue that this is not the semantics we would want. My interpretation of the proposed solution is: "I propose the following operators: really_is, really_as, really_as?, and really_as!. These operators would only return a positive result if the type actually was what was being asked for, instead of something that might be able to bridge to that type or a superclass of that type." We discussed the exhaustive pattern matching previously in this thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018799.html where the “exact match” cast operators were called `isExactly` and `asExactly`. I think the exhaustive pattern matching use case for classes (and protocols if / when we get sealed protocols) is an important one. I also think doing it right requires the ability to match exact types (i.e. not match subclasses). Maybe there is a better mechanism than a new operators but they would certainly do the job well. > > Do you have an alternative in mind for exhaustive pattern matching if we do > not introduce exact match cast operators? > >> >> ~Robert Widmann >> >>> On Aug 24, 2016, at 5:08 PM, Charles Srstka via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> MOTIVATION: >>> >>> SE-0083 appears to be dead in the water, having been deferred until later >>> in Swift 3 back in May and not having been heard from since then, with the >>> Swift 3 release looming closer and closer. However, the predictability >>> gains that would have been provided by this change remain desirable for >>> cases where one needs to know the actual dynamic type of an entity before >>> any bridging magic is involved. Additionally, performance-critical code may >>> desire the ability to check something’s type quickly without incurring the >>> overhead of Objective-C bridging code. >>> >>> PROPOSED SOLUTION: >>> >>> I propose the following operators: really_is, really_as, really_as?, and >>> really_as!. These operators would only return a positive result if the type >>> actually was what was being asked for, instead of something that might be >>> able to bridge to that type. >>> >>> DETAILED DESIGN: >>> >>> let foo: Any = "Foo" >>> let bar: Any = NSString(string: "Bar") >>> >>> let fooIsString = foo is String // true >>> let fooReallyIsString = foo really_is String // true >>> >>> let fooIsNSString = foo is NSString // true >>> let fooReallyIsNSString = foo really_is NSString // false >>> >>> let barIsString = bar is String // true >>> let barReallyIsString = bar really_is String // false >>> >>> let barIsNSString = bar is NSString // true >>> let barReallyIsNSString = bar really_is NSString // true >>> >>> ALTERNATIVES CONSIDERED: >>> >>> Stick with using an unholy combination of Mirror and unsafeBitCast when you >>> need to know what you’ve actually got. >>> >>> Charles >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
