[swift-evolution] [Review] SE-0024 "Optional Value Setter `??=`"

[James Campbell]

Interesting what if instead of ??? it was ?! (Take an optional "?", unwrap
to a default value if needed "!" and set it "=")

*___________________________________*

*James⎥Head of Awesome*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Feb 18, 2016 at 2:14 AM, Ross O'Brien via swift-evolution <
swift-evolution at swift.org> wrote:

> >       • What is your evaluation of the proposal?
>
> I'm for the adoption of this operator.
>
> Acknowledging previous comments: Swift values non-optional and immutable
> types, but I don't see this operator as encouraging optionals or mutable
> types; instead I see it as one step in the process of make clearer how
> mutable optionals are used. They aren't going anywhere.
>
> The difficulties of '??=' lie with '??', because it's overloaded; it
> serves both of these signatures:
> 1) Optional<T> ?? Optional<T> -> Optional<T>
> 2) Optional<T> ?? T -> T
> If we disambiguated this operator - for the sake of example, replaced the
> operator in 1) with '???' and kept 2) as is - then '??=' would be
> meaningless (its left argument would never be optional) and this proposal
> would instead be for the inclusion of '???=', which would be unambiguous.
> And the number of question marks alone would drown the developer in doubt
> until they went for the straightforward non-optional constant others in
> this thread feel this operator would encourage.
>
> As a further suggestion: just as the Swift compiler will currently warn a
> developer that a local variable is unused (and suggest replacing it with
> '_') or that a variable doesn't change (and suggest replacing its
> declaration with '??'), perhaps it could be possible to identify situations
> where an optional var could be replaced with a non-optional let if a '??='
> statement was rewritten as '??', and issue an appropriate warning.
>
> >       • Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> Swift encourages non-optionals. This isn't a significant problem,
> particularly if one follows the law of Demeter as one codes. But it's a
> nice addition.
>
> >       • Does this proposal fit well with the feel and direction of Swift?
>
> Yes. Swift will continue to have optionals, and code handling optionals
> should be clear. As long as the meaning of ?? is clearly understood, ??=
> will be.
>
> >       • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> I haven't used a similar feature in other languages, but have previously
> wished for such an operator in Objective C (prior to its
> nullable/nonnullable additions).
>
> >       • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> I've read the proposal and much of the swift-evolution discussion of it.
>
> On Wed, Feb 17, 2016 at 5:47 PM, Tal Atlas via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I think that overall this is a good operator that eventually should get
>> in. At this point though the wins that this would bring are probably not
>> worth the added complexity to the language.
>>
>> As Joe said the primary use case for the hammer operator `||=` in ruby is
>> not even covered by this operator, so it’s use would be far more limited
>> than in those languages.
>>
>> -Tal
>>
>> On Sat, Feb 13, 2016 at 12:15 AM, Douglas Gregor via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Hello Swift community,
>>>
>>> The review of SE-0024 "Optional Value Setter `??=`" begins now and runs
>>> through February 18, 2016. The proposal is available here:
>>>
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md
>>>
>>> Reviews are an important part of the Swift evolution process. All
>>> reviews should be sent to the swift-evolution mailing list at
>>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> or, if you would like to keep your feedback private, directly to the
>>> review manager. When replying, please try to keep the proposal link at the
>>> top of the message:
>>>
>>> Proposal link:
>>>
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md
>>>
>>> Reply text
>>>
>>> Other replies
>>>
>>> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What
>>> goes into a review?
>>>
>>> The goal of the review process is to improve the proposal under review
>>> through constructive criticism and, eventually, determine the direction of
>>> Swift. When writing your review, here are some questions you might want to
>>> answer in your review:
>>>
>>>    - What is your evaluation of the proposal?
>>>    - Is the problem being addressed significant enough to warrant a
>>>    change to Swift?
>>>    - Does this proposal fit well with the feel and direction of Swift?
>>>    - If you have used other languages or libraries with a similar
>>>    feature, how do you feel that this proposal compares to those?
>>>    - How much effort did you put into your review? A glance, a quick
>>>    reading, or an in-depth study?
>>>
>>> More information about the Swift evolution process is available at
>>>
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>
>>> Thank you,
>>>
>>> Doug Gregor
>>>
>>> Review Manager
>>>
>>> _______________________________________________
>>> 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/20160218/f773ad43/attachment.html>