[swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

Jacob Bandes-Storch jtbandes at gmail.com
Sat Sep 3 23:45:26 CDT 2016


>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0140-bridge-optional-to-nsnull.md
>
>
>    - What is your evaluation of the proposal?
>
> I tend to agree with other commenters that NSNull does not seem like an
obviously-correct (or -unsurprising) solution to this problem. Rather than
getting "unexpectedly found nil" errors like in Swift, this would start
causing more obtuse errors about missing methods on NSNull.

Users could simply be forced to write `?? NSNull()` if they really want to
use NSNull.

I do think that a warning/error for Optional<T>-to-Any conversion should be
added; something like:

    - (void)test:(id _Nonnull)arg;
    let x: Int? = 3
    test(x)  // passing optional type 'Int?' to 'Any' parameter uses an
opaque wrapper; use 'as Any' to silence this warning

Although, I'm not sure that would be a complete solution, because you could
still get around it with generic algorithms. This example is contrived, but:

    extension Array {
        func asAnys() -> [Any] {
            return map { $0 as Any }    // no warning here; $0's type is
Element, not known whether optional or non-optional
        }
    }

It might be nice for this warning to occur *only* when passing values to
Obj-C methods. Swift code written using Any would handle them correctly.
However, I'm not sure that's possible, given that the Obj-C importer
recently started using Any instead of AnyObject on purpose to make Obj-C
code more like Swift code in that way.


>
>    - Is the problem being addressed significant enough to warrant a
>    change to Swift?
>
> Definitely; the current behavior is surprising and dangerous.



>
>    - Does this proposal fit well with the feel and direction of Swift?
>
> Not really; it seems like a Cocoa-ism leaking into the purity/safety of
Swift, more so than most bridging behavior, although perhaps I'm only
saying this because NSNull is much less commonly used than the most other
bridged types.



>
>    - If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
>
> N/A



>
>    - How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> A quick reading of the proposal, plus some experimentation in a sample
project and discussion with others in Slack about an occurrence of the
motivating problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160903/246da7fa/attachment.html>


More information about the swift-evolution mailing list