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

[Taras_Zakharko1 (Taras Zakharko)]

I think the proposal should include some discussion on the common cases where this operator would be useful. As such, I don’t see much hard of including this, except that I am not sure that the problem is significant enough to warrant a reaction.

— T

···

On 13 Feb 2016, at 11:11, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

+0.5

I am generally for this proposal, because I don’t see why not — there are cases where this is useful, and it’s symmetric with other X/X= operator pairs, so it’s not like it’s a completely new thing.

However, I don’t think the operator is _as_ useful in Swift as it is in other languages.

In Ruby, for example, it’s extremely common to use `||=` (an equivalent of ??=, more or less) to modify function arguments, e.g. assign default values if nil was passed. But you can’t do that in Swift since SE-0003 removed the ability to mark a parameter as `var`.

So you can’t do that

  arg ??= default

and you have to do

  let arg = arg ?? default

Except you wouldn’t want the earlier version anyway, because `arg` would continue to be an optional. A notion not relevant in a dynamically typed language, but in Swift, it matters.

And I see other cases like this. A proposal to add `??=` to Swift was one of the first Swift radars I filed, because it was just something I was really used to. But with time I realized there are actually relatively few cases where this is useful. And that’s all because of Swift’s characteristics: it’s statically typed, it pushes you to use constants and not variables where possible, optionality is explicit, and avoided when not necessary.

Still, I searched through my code and found _a few_ instances of `??=` (my own implementation), almost all used for dealing with dictionaries (and a dictionary-like structure in a library called SwiftyUserDefaults) — and having this operator definitely improved the clarity of those places.

What is your evaluation of the proposal?

All in all, I’m for.

Is the problem being addressed significant enough to warrant a change to Swift?

I’d say yes, because it’s simple to implement, and carries little risk AFAICT. Still, it’s not as significant an improvement as many of the other proposals.

Does this proposal fit well with the feel and direction of Swift?

Again, ??= is only useful in _some_ cases, and in many other cases you want to avoid optionality and mutability. So it’s not necessarily something we want to encourage a lot, but I don’t see real risk in people trying to damage their Swift code just so they can use ??=. And OTOH having nice tools for dealing with optionality when it’s necessary is a very Swifty thing to do, so overall, yes.

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

Mostly dynamically typed languages with ||=, Ruby in particular. Also my own implementation of ??= in my projects and GitHub - sunshinejr/SwiftyUserDefaults: Modern Swift API for NSUserDefaults

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.

Best,
— Radek

On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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@swift.org <mailto: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

[hlovatt (Howard Lovatt)]

Nuetral on this. Not a major problem but then again it is just a library
addition.

···

On Saturday, 13 February 2016, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

On 13 Feb 2016, at 05:15, Douglas Gregor via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

   - What is your evaluation of the proposal?

I’m in favour of it, for some reason I encounter cases like these a lot,
so a simplified operator would be great.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

It’s not exactly a major problem, but clean code is always good and it
should be a fairly simple feature.

   - Does this proposal fit well with the feel and direction of Swift?

Yes.

   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

Quick reading, but the proposal is self-explanatory.

--
-- Howard.

[owensd (David Owens II)]

I just want to throw this out in case it changes your opinion - while the book does say that, the Swift library defines both of these:

@warn_unused_result
public func ??<T>(optional: T?, @autoclosure defaultValue: () throws -> T?) rethrows -> T?
@warn_unused_result
public func ??<T>(optional: T?, @autoclosure defaultValue: () throws -> T) rethrows -> T

This has the side-effect that this is legal code already today:

var o: Int? = nil
o = o ?? nil

I agree ??= has a much smaller surface area of potential use cases though.

A lot of times I have a need for something like this is when I'm parsing data into an unstructured type that will then later be realized into a strong type further in the pipeline.

-David

···

On Feb 13, 2016, at 11:52 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

-1, on the basis of use being a potential anti-pattern, and the spec focusing on the benefit of a terser syntax over possible uses.

If there are additional uses outside the proposal, this evaluation may change.

Is the problem being addressed significant enough to warrant a change to Swift?

Not as described.

“??” is described as the nil coalescing operator. It is defined as the following function:

public func ??<T>(optional: T?, @autoclosure defaultValue: () throws -> T) rethrows -> T
The purpose of the nil coalescing operator is defined as follows by the Swift Programming Language book

“The nil coalescing operator (a ?? b) unwraps an optional a if it contains a value, or returns a default value b if a is nil. The expression a is always of an optional type. The expression b must match the type that is stored inside a.”

This operator has thus two core properties:
1. it allows another mechanism to deal with nil values, by specifying an alternate value to use in the nil case
2. as either the value or the alternate is non-nil, it casts off optionality

This operator does not do the second. It allows you to apply a value in the nil case, but the resulting value is still an optional. As such, I fear the usefulness of the “??=“ operator is greatly diminished.

Note also that unlike other operators with inout equivalents like addition, the type of the left-hand input and the output are not the same in “??” due to the missing safe casting off of optionality.

Does this proposal fit well with the feel and direction of Swift?

The example given by the proposal is as follows:

really.long.lvalue[expression] = really.long.lvalue[expression] ?? ""

In this case, you are setting a default value of “” to an optional target within a long expression.

However, it is unclear why the original expression allowed nil, or why setting this value to “” is an improvement.

To counter, some existing usage:

let userDefaults = NSUserDefaults.standardUserDefaults()
let repeatCount = userDefaults.valueForKey("repeatCount") as? Int ?? 4
for attempt in 0..<repeatCount {
    // ...
}

The for loop only works because repeatCount is non-optional. Assigning the value back into the expression would mutate the original value, but would still require one to cast off the optionality of the value.

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

As mentioned, Ruby has a similar behavior. Other than the “false” and “nil” literal values, everything evaluates as true. The || and && operators preserve the values of the lhs and rhs arguments.

1 && 2 # is 2
1 || 2 # is 1
nil || 2 # is 2

As such, ||= can be used for such a default assignment system.

However, ruby does not have optionality. All libraries must take into account the possibility of sending nil in for a value. As such, it is not influenced by the limitations of this proposal.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-between a reading and a study.

-DW

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Ross_O_Brien]

"y is assigned to x if x is nil" *is* exactly what "x ??= y" means. If x is
nil, x is assigned the value of y; if x is not nil, it doesn't matter what
y is.

This is exactly consistent with the boolean operator ||= ; "x ||= y" means
"y is assigned to x if x is false" - if x is false, x is assigned the value
of y; if x is true, it doesn't matter what y is.)

Why do you think it means the opposite?

···

On Tue, Feb 16, 2016 at 1:24 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

-1, because in my mind, "x ??= y" kinda looks like "y is assigned to x iff
y isn't nil", or, if you associate the ?? part with the lhs, "y is assigned
to x if x is nil", neither of which is what the proposed operator means. In
fact, the 2nd case is the *opposite* of what ??= means in this proposal.

To be clear, it's the syntax that I'm opposed to, not the concept.

- Dave Sweeris

On Feb 12, 2016, at 23:15, Douglas Gregor <dgregor@apple.com> 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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[cryo (Sune Foldager)]

…and I of course meant Ruby when I said Python :p

-Sune

···

On 16 Feb 2016, at 19:38, Sune Foldager <cyano@me.com> wrote:

On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What is your evaluation of the proposal?

I’m -1. My main objection is the same as others have brought up, namely that, contrary to ??, it keeps us in “optional land”. That is, a ??= b ~> a = a ?? b, so a must be optional.

Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think so. In Python, where ||= works, I do use that from time to time because it’s “idiomatic”, but I don’t really think it’s very obvious what it does. In Swift, my programming style is a bit different, and I don’t find myself needing it. Especially due to the way it keeps optional (which is obviously not an issue in Python).

Does this proposal fit well with the feel and direction of Swift?

I don’t know, but I don’t think it’s a very important addition and can lead to confusion instead.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the responses. Thought about my own use, and looked at some Python and Swift code.

-Sune

[pyrtsa (Pyry Jahkola)]

Below is my -1 on the proposal. But before that:

I think a more expressive alternative approach to this problem would be to extend Dictionary with a `subscript(_:orDefault:)` member:

extension Dictionary {
  subscript(key: Key, orDefault value: Value) -> Value { … }
}

I think it's really a shortcoming in Dictionary's interface, where the general use case of updating a key in place usually asks for a lot of boilerplate. Thinking outside the box somewhat, one way to make all kinds of updates—"upserts", accumulating the value, but also removals—possible would be to extend Optional's interface with this simple addition:

extension Optional {
    public mutating func rewrap(@noescape transform: Wrapped? throws -> Wrapped?) rethrows {
        self = try transform(self)
    }
}

Conditionally inserting a key would then be:

var dict = [2: "two"]
dict[1].rewrap {$0 ?? "one"}
dict[2].rewrap {$0 ?? "deux"} // no-op
// dict == [2: "two", 1: "one"]

Maintaining a set of counters:

var counts = [String: Int]()
let increment: Int? -> Int? = {($0 ?? 0) + 1}
let decrement: Int? -> Int? = {
    let n = ($0 ?? 0) - 1
    return n == 0 ? nil : n
}
counts["Söze"].rewrap(increment)
counts["Kujan"].rewrap(increment)
counts["Kint"].rewrap(increment)
counts["Söze"].rewrap(decrement) // poof… he's gone
counts["Kint"].rewrap(increment)
// counts == ["Kujan": 1, "Kint": 2]

Originally I thought calling it simply update, however rewrap has a closer correspondence to Optional's Wrapped, and might thus be less ambiguous.

— — —

What comes to the proposal then…

What is your evaluation of the proposal?

-1.

Is the problem being addressed significant enough to warrant a change to Swift?

I don't think this is the problem to be addressed. The issue here is that even after the update, the result is still an optional, so there's no promise that it'll have a non-nil value. I have a feeling guard could be used in most of these use cases for a better design. And lazy loading or set-once properties might help a bit too.

Does this proposal fit well with the feel and direction of Swift?

It's true that we have the in-place mutating op= variant of many operators op which happen to return the same type as their first argument. However, I see ?? as two overloads ((T?, T) -> T and (T?, T?) -> T?), the one returning non-optional being the more official one which is somewhat against the current practice.

I also feel the use of this operator would leave too many T? hanging around where T would do.

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

Ruby comes in mind. Ruby is different in that it does nothing to prevent the Billion Dollar Mistake that they coincidentally call nil.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've followed the conversation for a couple of days and read through the proposal quickly. I've thought about the problem domain a lot before though.

— Pyry Jahkola

···

On 16 Feb 2016, at 20:26, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

[trs (Thorsten Seitz)]

-1 to the proposal.

Kevin and others have summed up the reasons already: the operator is encouraging mutability and optionality where it would not be needed and using it therefore seems to be an anti pattern.

-Thorsten

···

Am 17.02.2016 um 06:26 schrieb Kevin Ballard via swift-evolution <swift-evolution@swift.org>:

On Fri, Feb 12, 2016, at 09:15 PM, Douglas Gregor wrote:
What is your evaluation of the proposal?

-1. If we were to have this operator, then I think `??=` is a good choice for it. But I don't think we need this operator. As others have pointed out, a lot of the use-cases from other languages don't actually work in Swift, and having the operator encourages people to write anti-patterns in order to use it, such as making a value into a mutable Optional when it really should be an immutable non-optional value.

Is the problem being addressed significant enough to warrant a change to Swift?

No. The need for this sort of operator is much rarer in Swift than it is in languages that do have an equivalent (like Ruby).

Anecdotally, I've written a lot of Swift code at this point, and I've never wanted this. I have on rare occasion wanted a local "lazy" variable, but in those rare instances, the desire was to move the initialization out of the main body of the function and up to the declaration, which `??=` doesn't help with.

Does this proposal fit well with the feel and direction of Swift?

The choice of operator I think is reasonable, given the existing `??` operator, but encouraging the use of Optionals for local variables that will end up with a guaranteed-non-Optional value does not.

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

The only languages that I know of with a similar operator also return the rhs value from the assignment expression, and that's not something Swift would do. So this is less useful than the operator in those languages.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

-Kevin Ballard
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Andrew (Andrew Bennett)]

- What is your evaluation of the proposal?

-1. Kevin Ballard seems to have covered my reasons quite well.

   - Is the problem being addressed significant enough to warrant a change
   to Swift?

No. Again, Kevin Ballard has covered it. I think it encourages mutability
where it's not necessary, isn't useful without a return value, and
syntactically doesn't add much over `??`.

   - Does this proposal fit well with the feel and direction of Swift?

I think it adds unnecessary syntactic sugar and encourages bad (swift)
practices, which doesn't fit the feel and direction of Swift. I can
understand the desire for it, but every time I've wanted it I have used ??
and preferred the resulting code. The resulting code has felt more Swifty.
I suppose worst-case you can do this: `a = b ?? a`.

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

Other languages I've used have allowed this operator to be chained, used as
a style of lazy-initialization. Using this operator for that doesn't
guarantee that the value is set, and set once, there's better ways to do
that in Swift. Other cases I've seen it were to break expressions over
multiple lines, I think that's noisy, and prone to mistakes when
refactoring.

   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

Followed the discussion, read the proposal, read the last post (Kevin's).

- Andrew Bennett

···

On Wed, Feb 17, 2016 at 2:26 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote:

On Fri, Feb 12, 2016, at 09:15 PM, Douglas Gregor wrote:

   - What is your evaluation of the proposal?

-1. If we were to have this operator, then I think `??=` is a good choice
for it. But I don't think we need this operator. As others have pointed
out, a lot of the use-cases from other languages don't actually work in
Swift, and having the operator encourages people to write anti-patterns in
order to use it, such as making a value into a mutable Optional when it
really should be an immutable non-optional value.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

No. The need for this sort of operator is much rarer in Swift than it is
in languages that do have an equivalent (like Ruby).

Anecdotally, I've written a lot of Swift code at this point, and I've
never wanted this. I have on rare occasion wanted a local "lazy" variable,
but in those rare instances, the desire was to move the initialization out
of the main body of the function and up to the declaration, which `??=`
doesn't help with.

   - Does this proposal fit well with the feel and direction of Swift?

The choice of operator I think is reasonable, given the existing `??`
operator, but encouraging the use of Optionals for local variables that
will end up with a guaranteed-non-Optional value does not.

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

The only languages that I know of with a similar operator also return the
rhs value from the assignment expression, and that's not something Swift
would do. So this is less useful than the operator in those languages.

   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

A quick reading.

-Kevin Ballard

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Ross_O_Brien]

      • 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@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@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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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@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

[Ilya_Belenkiy]

+1 for the same reason (consistent with +=)

···

On Sat, Feb 13, 2016 at 1:29 AM Paul Ossenbruggen via swift-evolution < swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?
+1 this is seems like a natural addition similar to += or other operators
which assign and perform an action.

Is the problem being addressed significant enough to warrant a change to
Swift?
Yes.
Does this proposal fit well with the feel and direction of Swift?
Yes.

If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
Not found in other languages.

How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Read proposal and thread.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[James_Campbell]

One common case could be for a error catching, consider this:

let object = try? UnsupportedMessage(text: "James", type:.Text,
date:NSDate()) ?? FailedObject()

vs

var object = try? Message(text: "James", type:.Text, date:NSDate())
object ??= UnsupportedMessage()

Why would we need this? I have a chat application where if it gets a
message it doesn't understand it will throw an error. In the past I would
handle this errors by returning nil like so. However we want to communicate
to the user that they missing content by vending a UnsupportedMessage
object which shows the UI to prompt them to upgrade.

If the object being constructed has a lot of variables then it could be
lost off the side of the screen. I feel ??= is more concise in this case.

This could also be great for the null object pattern where you may not want
a variable to be nil, you may want some sort of null object that is vended
in cases of failure that could log this error.

···

*___________________________________*

*James⎥Head of Awesome*

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

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sat, Feb 13, 2016 at 11:20 AM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote:

I think the proposal should include some discussion on the common cases
where this operator would be useful. As such, I don’t see much hard of
including this, except that I am not sure that the problem is significant
enough to warrant a reaction.

— T

On 13 Feb 2016, at 11:11, Radosław Pietruszewski via swift-evolution < > swift-evolution@swift.org> wrote:

+0.5

I am generally for this proposal, because I don’t see why not — there are
cases where this is useful, and it’s symmetric with other X/X= operator
pairs, so it’s not like it’s a completely new thing.

However, I don’t think the operator is _as_ useful in Swift as it is in
other languages.

In Ruby, for example, it’s extremely common to use `||=` (an equivalent of
??=, more or less) to modify function arguments, e.g. assign default values
if nil was passed. But you can’t do that in Swift since SE-0003 removed the
ability to mark a parameter as `var`.

So you can’t do that

arg ??= default

and you have to do

let arg = arg ?? default

Except you wouldn’t want the earlier version anyway, because `arg` would
continue to be an optional. A notion not relevant in a dynamically typed
language, but in Swift, it matters.

And I see other cases like this. A proposal to add `??=` to Swift was one
of the first Swift radars I filed, because it was just something I was
really used to. But with time I realized there are actually relatively few
cases where this is useful. And that’s all because of Swift’s
characteristics: it’s statically typed, it pushes you to use constants and
not variables where possible, optionality is explicit, and avoided when not
necessary.

Still, I searched through my code and found _a few_ instances of `??=` (my
own implementation), almost all used for dealing with dictionaries (and a
dictionary-like structure in a library called SwiftyUserDefaults) — and
having this operator definitely improved the clarity of those places.

   - What is your evaluation of the proposal?

All in all, I’m for.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

I’d say yes, because it’s simple to implement, and carries little risk
AFAICT. Still, it’s not as significant an improvement as many of the other
proposals.

   - Does this proposal fit well with the feel and direction of Swift?

Again, ??= is only useful in _some_ cases, and in many other cases you
want to avoid optionality and mutability. So it’s not necessarily something
we want to encourage a lot, but I don’t see real risk in people trying to
damage their Swift code just so they can use ??=. And OTOH having nice
tools for dealing with optionality when it’s necessary is a very Swifty
thing to do, so overall, yes.

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

Mostly dynamically typed languages with ||=, Ruby in particular. Also my
own implementation of ??= in my projects and
GitHub - sunshinejr/SwiftyUserDefaults: Modern Swift API for NSUserDefaults

   - 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.

Best,
— Radek

On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution < > swift-evolution@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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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@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

[Radek_Pietruszewski]

I disagree. I think those are exactly the wrong use cases for ??= and, in fact, could be used as an argument against this proposal (??= encouraging unidiomatic behavior).

let object = try? UnsupportedMessage(text: "James", type:.Text, date:NSDate()) ?? FailedObject()

vs

var object = try? Message(text: "James", type:.Text, date:NSDate())
object ??= UnsupportedMessage()

The first example — though an admittedly long line — is clearly better to my eyes.

The second one does *two* things considered undesirable in Swift:

- it creates a mutable variable even though it’s not necessary
- it leaves `object` as an Optional, even though we don’t mean it to actually ever be nil.

This could also be great for the null object pattern where you may not want a variable to be nil, you may want some sort of null object that is vended in cases of failure that could log this error.

I agree with the premise — a null object or value is often much better than a nil (e.g. vs nil when there isn’t a semantic diff between the two). But when you use ??=, the variable you’re mutating is still an Optional and could be nil!

* * *

I see two reasons to use ??=:

- when applying a default value to a dictionary (or a dictionary-like structure), since subscripting it will produce Optionals *either way*
- when mutating a property (not a local variable!), that is (has to be) optional and mutable *either way*

It’s a useful shortcut in those two circumstances. But it is not desirable to damage our Swift code with needless optionals or mutability so we can use ??=.

best,
— Radek

···

On 13 Feb 2016, at 13:10, James Campbell <james@supmenow.com> wrote:

One common case could be for a error catching, consider this:

let object = try? UnsupportedMessage(text: "James", type:.Text, date:NSDate()) ?? FailedObject()

vs

var object = try? Message(text: "James", type:.Text, date:NSDate())
object ??= UnsupportedMessage()

Why would we need this? I have a chat application where if it gets a message it doesn't understand it will throw an error. In the past I would handle this errors by returning nil like so. However we want to communicate to the user that they missing content by vending a UnsupportedMessage object which shows the UI to prompt them to upgrade.

If the object being constructed has a lot of variables then it could be lost off the side of the screen. I feel ??= is more concise in this case.

This could also be great for the null object pattern where you may not want a variable to be nil, you may want some sort of null object that is vended in cases of failure that could log this error.

___________________________________

James⎥Head of Awesome

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On Sat, Feb 13, 2016 at 11:20 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I think the proposal should include some discussion on the common cases where this operator would be useful. As such, I don’t see much hard of including this, except that I am not sure that the problem is significant enough to warrant a reaction.

— T

On 13 Feb 2016, at 11:11, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+0.5

I am generally for this proposal, because I don’t see why not — there are cases where this is useful, and it’s symmetric with other X/X= operator pairs, so it’s not like it’s a completely new thing.

However, I don’t think the operator is _as_ useful in Swift as it is in other languages.

In Ruby, for example, it’s extremely common to use `||=` (an equivalent of ??=, more or less) to modify function arguments, e.g. assign default values if nil was passed. But you can’t do that in Swift since SE-0003 removed the ability to mark a parameter as `var`.

So you can’t do that

  arg ??= default

and you have to do

  let arg = arg ?? default

Except you wouldn’t want the earlier version anyway, because `arg` would continue to be an optional. A notion not relevant in a dynamically typed language, but in Swift, it matters.

And I see other cases like this. A proposal to add `??=` to Swift was one of the first Swift radars I filed, because it was just something I was really used to. But with time I realized there are actually relatively few cases where this is useful. And that’s all because of Swift’s characteristics: it’s statically typed, it pushes you to use constants and not variables where possible, optionality is explicit, and avoided when not necessary.

Still, I searched through my code and found _a few_ instances of `??=` (my own implementation), almost all used for dealing with dictionaries (and a dictionary-like structure in a library called SwiftyUserDefaults) — and having this operator definitely improved the clarity of those places.

What is your evaluation of the proposal?

All in all, I’m for.

Is the problem being addressed significant enough to warrant a change to Swift?

I’d say yes, because it’s simple to implement, and carries little risk AFAICT. Still, it’s not as significant an improvement as many of the other proposals.

Does this proposal fit well with the feel and direction of Swift?

Again, ??= is only useful in _some_ cases, and in many other cases you want to avoid optionality and mutability. So it’s not necessarily something we want to encourage a lot, but I don’t see real risk in people trying to damage their Swift code just so they can use ??=. And OTOH having nice tools for dealing with optionality when it’s necessary is a very Swifty thing to do, so overall, yes.

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

Mostly dynamically typed languages with ||=, Ruby in particular. Also my own implementation of ??= in my projects and GitHub - sunshinejr/SwiftyUserDefaults: Modern Swift API for NSUserDefaults

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.

Best,
— Radek

On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[David_Sweeris]

Oops, I meant “if x is not nil”. Everywhere else, the ? or ?? "goes through” when the value in question is not nil. In this case, something happens when the value *is* nil.

···

On Feb 16, 2016, at 8:13 AM, Ross O'Brien <narrativium+swift@gmail.com> wrote:

"y is assigned to x if x is nil" is exactly what "x ??= y" means. If x is nil, x is assigned the value of y; if x is not nil, it doesn't matter what y is.

This is exactly consistent with the boolean operator ||= ; "x ||= y" means "y is assigned to x if x is false" - if x is false, x is assigned the value of y; if x is true, it doesn't matter what y is.)

Why do you think it means the opposite?

On Tue, Feb 16, 2016 at 1:24 PM, David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1, because in my mind, "x ??= y" kinda looks like "y is assigned to x iff y isn't nil", or, if you associate the ?? part with the lhs, "y is assigned to x if x is nil", neither of which is what the proposed operator means. In fact, the 2nd case is the *opposite* of what ??= means in this proposal.

To be clear, it's the syntax that I'm opposed to, not the concept.

- Dave Sweeris

On Feb 12, 2016, at 23:15, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> 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
<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. 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-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[James_Campbell]

Granted it may be confusing since other languages use the Or operator which reads better.
X ||= y
However I would argue that this operator has no choice but to use ??= Since it is a mirror for the ?? Operation.
Perhaps it would be better for the language if ?? Was actually || but this would be a small but big change and would belong in another proposal.

···

Sent from Supmenow.com

On Tue, Feb 16, 2016 at 6:14 AM -0800, "Ross O'Brien via swift-evolution" <swift-evolution@swift.org> wrote:

"y is assigned to x if x is nil" is exactly what "x ??= y" means. If x is nil, x is assigned the value of y; if x is not nil, it doesn't matter what y is.
This is exactly consistent with the boolean operator ||= ; "x ||= y" means "y is assigned to x if x is false" - if x is false, x is assigned the value of y; if x is true, it doesn't matter what y is.)
Why do you think it means the opposite?

On Tue, Feb 16, 2016 at 1:24 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
-1, because in my mind, "x ??= y" kinda looks like "y is assigned to x iff y isn't nil", or, if you associate the ?? part with the lhs, "y is assigned to x if x is nil", neither of which is what the proposed operator means. In fact, the 2nd case is the *opposite* of what ??= means in this proposal.
To be clear, it's the syntax that I'm opposed to, not the concept.
- Dave Sweeris
On Feb 12, 2016, at 23:15, Douglas Gregor <dgregor@apple.com> 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:swift-evolution/0024-optional-value-setter.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list athttps://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:swift-evolution/0024-optional-value-setter.md at master · apple/swift-evolution · GitHub

Reply textOther repliesWhat 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 athttps://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Doug Gregor

Review Manager_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

[James_Campbell]

So what would you guys feel to exposing a subscript method like mentioned,
like so:

dict.subscript("key", default:"value")
dict.("key", default:"value")
dict["key", default:"value"]

···

*___________________________________*

*James⎥Head of Awesome*

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

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Tue, Feb 16, 2016 at 6:42 PM, Sune Foldager via swift-evolution < swift-evolution@swift.org> wrote:

…and I of course meant Ruby when I said Python :p

-Sune

On 16 Feb 2016, at 19:38, Sune Foldager <cyano@me.com> wrote:

On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

   - What is your evaluation of the proposal?

I’m -1. My main objection is the same as others have brought up, namely
that, contrary to ??, it keeps us in “optional land”. That is, a ??= b ~> a
= a ?? b, so a must be optional.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

I don’t think so. In Python, where ||= works, I do use that from time to
time because it’s “idiomatic”, but I don’t really think it’s very obvious
what it does. In Swift, my programming style is a bit different, and I
don’t find myself needing it. Especially due to the way it keeps optional
(which is obviously not an issue in Python).

   - Does this proposal fit well with the feel and direction of Swift?

I don’t know, but I don’t think it’s a very important addition and can
lead to confusion instead.

   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

Read the responses. Thought about my own use, and looked at some Python
and Swift code.

-Sune

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[James_Campbell]

You could argue that rewrap is just flatMap

···

*___________________________________*

*James⎥Head of Awesome*

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

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Tue, Feb 16, 2016 at 7:44 PM, Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote:

Below is my -1 on the proposal. But before that:

On 16 Feb 2016, at 20:26, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

I think a more expressive alternative approach to this problem would be to
extend Dictionary with a `subscript(_:orDefault:)` member:

extension Dictionary {
  subscript(key: Key, orDefault value: Value) -> Value { … }
}

I think it's really a shortcoming in Dictionary's interface, where the
general use case of updating a key in place usually asks for a lot of
boilerplate. Thinking outside the box somewhat, one way to make all kinds
of updates—"upserts", accumulating the value, but also removals—possible
would be to extend Optional's interface with this simple addition:

extension Optional {
    public mutating func rewrap(@noescape transform: Wrapped? throws ->
Wrapped?) rethrows {
        self = try transform(self)
    }
}

Conditionally inserting a key would then be:

var dict = [2: "two"]
dict[1].rewrap {$0 ?? "one"}
dict[2].rewrap {$0 ?? "deux"} // no-op
// dict == [2: "two", 1: "one"]

Maintaining a set of counters:

var counts = [String: Int]()
let increment: Int? -> Int? = {($0 ?? 0) + 1}
let decrement: Int? -> Int? = {
    let n = ($0 ?? 0) - 1
    return n == 0 ? nil : n
}
counts["Söze"].rewrap(increment)
counts["Kujan"].rewrap(increment)
counts["Kint"].rewrap(increment)
counts["Söze"].rewrap(decrement) // poof… he's gone
counts["Kint"].rewrap(increment)
// counts == ["Kujan": 1, "Kint": 2]

Originally I thought calling it simply update, however rewrap has a
closer correspondence to Optional's Wrapped, and might thus be less
ambiguous.

— — —

What comes to the proposal then…

What is your evaluation of the proposal?

-1.

Is the problem being addressed significant enough to warrant a change to
Swift?

I don't think this is the problem to be addressed. The issue here is that
even after the update, the result is still an optional, so there's no
promise that it'll have a non-nil value. I have a feeling guard could be
used in most of these use cases for a better design. And lazy loading or
set-once properties might help a bit too.

Does this proposal fit well with the feel and direction of Swift?

It's true that we have the in-place mutating op= variant of many
operators op which happen to return the same type as their first
argument. However, I see ?? as two overloads ((T?, T) -> T and (T?, T?)
-> T?), the one returning non-optional being the more official one which
is somewhat against the current practice.

I also feel the use of this operator would leave too many T? hanging
around where T would do.

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

Ruby comes in mind. Ruby is different in that it does nothing to prevent
the Billion Dollar Mistake that they coincidentally call nil.

How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I've followed the conversation for a couple of days and read through the
proposal quickly. I've thought about the problem domain a lot before though.

— Pyry Jahkola

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[stephencelis]

  • What is your evaluation of the proposal?

I'm against the adoption of this operator. Echoing previous comments:

- Its use can encourage mutability and optionality where immutability and unwrapped types would be preferred
- Its surface area is smaller than the breadth that it covers—as Joe mentioned earlier, a Dictionary extension may be a better proposed solution

I also believe that inclusion in the standard library is an endorsement, and developers coming from other languages with similar operators will adopt its use in scenarios that would be better addressed with careful consideration of mutability and optionality.

  • Is the problem being addressed significant enough to warrant a change to Swift?

No. It could create more problems than it solves.

  • Does this proposal fit well with the feel and direction of Swift?

Other than the fact that it fits in with the other operators, no. While Swift makes optionals and mutating state easy to work with, it also prefers immutability (it generates fix-its to change "var" to "let") and non-optional types are still much easier (and safer) to work with.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've used Ruby extensively and it's generally a good fit there given the prevalence of nil and mutating state in the language and how the language is generally written. It makes much less sense for Swift for the reasons I mentioned earlier.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I participated in the earlier discussions, thought about it at length, and looked over my own code to consider where it would be useful.

Stephen

[stephencelis]

If conciseness is your goal, isn't "??" more concise here? (It's a single line—rather than two—and fewer characters.)

If you're worried about line length and/or readability, have you considered using a newline to break the logic up?

    let object = try? UnsupportedMessage(text: "James", type:.Text, date:NSDate())
        ?? FailedObject()

This way

- the result isn't mutable and
- the result isn't optional

Stephen

···

On Feb 13, 2016, at 7:10 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

One common case could be for a error catching, consider this:

let object = try? UnsupportedMessage(text: "James", type:.Text, date:NSDate()) ?? FailedObject()

vs

var object = try? Message(text: "James", type:.Text, date:NSDate())
object ??= UnsupportedMessage()

Why would we need this? I have a chat application where if it gets a message it doesn't understand it will throw an error. In the past I would handle this errors by returning nil like so. However we want to communicate to the user that they missing content by vending a UnsupportedMessage object which shows the UI to prompt them to upgrade.

If the object being constructed has a lot of variables then it could be lost off the side of the screen. I feel ??= is more concise in this case.

[trs (Thorsten Seitz)]

What is the difference to just using

dict[key] ?? "value"

-Thorsten

···

Am 16.02.2016 um 20:12 schrieb James Campbell via swift-evolution <swift-evolution@swift.org>:

So what would you guys feel to exposing a subscript method like mentioned, like so:

dict.subscript("key", default:"value")
dict.("key", default:"value")
dict["key", default:"value"]

___________________________________

James⎥Head of Awesome

james@supmenow.com⎥supmenow.com

Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On Tue, Feb 16, 2016 at 6:42 PM, Sune Foldager via swift-evolution <swift-evolution@swift.org> wrote:
…and I of course meant Ruby when I said Python :p

-Sune

On 16 Feb 2016, at 19:38, Sune Foldager <cyano@me.com> wrote:

On 13 Feb 2016, at 06:15, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

I’m -1. My main objection is the same as others have brought up, namely that, contrary to ??, it keeps us in “optional land”. That is, a ??= b ~> a = a ?? b, so a must be optional.

Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think so. In Python, where ||= works, I do use that from time to time because it’s “idiomatic”, but I don’t really think it’s very obvious what it does. In Swift, my programming style is a bit different, and I don’t find myself needing it. Especially due to the way it keeps optional (which is obviously not an issue in Python).

Does this proposal fit well with the feel and direction of Swift?

I don’t know, but I don’t think it’s a very important addition and can lead to confusion instead.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the responses. Thought about my own use, and looked at some Python and Swift code.

-Sune

_______________________________________________
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

[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@supmenow.com <james@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@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@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@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

<GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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@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