[swift-evolution] Pitch: really_is and really_as operators

[Xiaodi Wu]

On Wed, Aug 24, 2016 at 9:25 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

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