> On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution > <[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. 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
