On Wed, Aug 24, 2016 at 9:25 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:
> > On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution < > swift-evolution@swift.org> 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? > 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 < > swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
