Proposal: An assignment operator := that ensures nil before assignment.

Evolution Discussion
1

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

2

You could use an `inout` function to solve this now without adding surface area to the language and standard lib.

I've noticed, Amir, that people often ask you to flesh these ideas out more before submitting them to evolution. Would you please address these questions on this (and future) proposals? It might speed these discussions along.

- Why do you want this feature?

- Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?

- Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?

Your emails to evolution are generally too short and not fleshed out enough to really evaluate.

Stephen

···

On Feb 27, 2016, at 9:34 AM, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

3

How is this different from the rejected ??= proposal?

···

On Sat, Feb 27, 2016 at 2:34 PM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

4

Expressing the constraint of “can’t be nil” is much better done via the type system, where the undesirable value is simply impossible. Instead of inducing crashes with innocently-looking special operator, just use a non-optional variable, and where you have to convert from an optional, unwrap it explicitly.

— Radek

···

On 27 Feb 2016, at 15:34, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

5

How is this different from the rejected ??= proposal?

If the value is not nil, the program stops with an assertion error.

···

On Feb 27, 2016, at 9:46 AM, Ross O'Brien <narrativium+swift@gmail.com> wrote:

On Sat, Feb 27, 2016 at 2:34 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

6

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

You could use an `inout` function to solve this now without adding surface area to the language and standard lib.

I think this := would be used so often that it should be part of the language/standard library.

···

On Feb 27, 2016, at 10:11 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 9:34 AM, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

I've noticed, Amir, that people often ask you to flesh these ideas out more before submitting them to evolution. Would you please address these questions on this (and future) proposals? It might speed these discussions along.

- Why do you want this feature?

- Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?

- Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?

Your emails to evolution are generally too short and not fleshed out enough to really evaluate.

Stephen

7

Expressing the constraint of “can’t be nil” is much better done via the type system, where the undesirable value is simply impossible. Instead of inducing crashes with innocently-looking special operator, just use a non-optional variable, and where you have to convert from an optional, unwrap it explicitly.

The constraint actually is “has to be nil”.

···

On Feb 27, 2016, at 11:32 AM, Radosław Pietruszewski <radexpl@gmail.com> wrote:

— Radek

On 27 Feb 2016, at 15:34, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

8

This is less desirable than ??= would have been. To summarise the two
operators:

lhs ??= rhs. lhs is an Optional<T>, rhs is a T or Optional<T>.
If lhs is nil, assign to lhs the value of rhs. If lhs is not nil, do
nothing.

lhs := rhs. lhs is an Optional<T>, rhs is a T or Optional<T>.
If lhs is nil, assign to lhs the value of rhs. If lhs is not nil, crash
with an assertion error.

The ??= operator is safer; its behaviour is clear and it doesn't cause my
code to crash. := is more dangerous; if I want to be sure my app won't
crash, I now need to check whether lhs is nil first... and if I do that, I
might as well use the = operator.

I don't see what advantages your operator brings to Swift, or why you think
it should be accepted when ??= operator was rejected.

···

On Sat, Feb 27, 2016 at 2:47 PM, Amir Michail <a.michail@me.com> wrote:

On Feb 27, 2016, at 9:46 AM, Ross O'Brien <narrativium+swift@gmail.com> > wrote:

How is this different from the rejected ??= proposal?

If the value is not nil, the program stops with an assertion error.

On Sat, Feb 27, 2016 at 2:34 PM, Amir Michail via swift-evolution < > swift-evolution@swift.org> wrote:

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

9

Apologies — I misunderstood.

In this case, like others, I would like to see a compelling snippet of code showing the use case for this. Without this context, I just don’t see why would you want to do it this way.

— Radek

···

On 27 Feb 2016, at 17:59, Amir Michail <a.michail@me.com> wrote:

On Feb 27, 2016, at 11:32 AM, Radosław Pietruszewski <radexpl@gmail.com> wrote:

Expressing the constraint of “can’t be nil” is much better done via the type system, where the undesirable value is simply impossible. Instead of inducing crashes with innocently-looking special operator, just use a non-optional variable, and where you have to convert from an optional, unwrap it explicitly.

The constraint actually is “has to be nil”.

— Radek

On 27 Feb 2016, at 15:34, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

10

This is less desirable than ??= would have been. To summarise the two operators:

lhs ??= rhs. lhs is an Optional<T>, rhs is a T or Optional<T>.
If lhs is nil, assign to lhs the value of rhs. If lhs is not nil, do nothing.

lhs := rhs. lhs is an Optional<T>, rhs is a T or Optional<T>.
If lhs is nil, assign to lhs the value of rhs. If lhs is not nil, crash with an assertion error.

The ??= operator is safer; its behaviour is clear and it doesn't cause my code to crash. := is more dangerous; if I want to be sure my app won't crash, I now need to check whether lhs is nil first... and if I do that, I might as well use the = operator.

I don't see what advantages your operator brings to Swift, or why you think it should be accepted when ??= operator was rejected.

This is how I write code. I use preconditions everywhere because I want to know about errors as soon as possible.

···

On Feb 27, 2016, at 10:02 AM, Ross O'Brien <narrativium+swift@gmail.com> wrote:

On Sat, Feb 27, 2016 at 2:47 PM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:

On Feb 27, 2016, at 9:46 AM, Ross O'Brien <narrativium+swift@gmail.com <mailto:narrativium+swift@gmail.com>> wrote:

How is this different from the rejected ??= proposal?

If the value is not nil, the program stops with an assertion error.

On Sat, Feb 27, 2016 at 2:34 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Consider the use of “!” in the following:

var x: Int? = 5

x! = 2 // “!” is used to ensure non-nil value before assignment

The idea is to have a similar method for ensuring a nil value.

So instead of writing:

precondition( x == nil )
x = 3

You could write:

x := 3

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

11

Would you please justify this? Would you please answer the questions from my reply?

Stephen

···

On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com> wrote:

I think this := would be used so often that it should be part of the language/standard library.

12

I think this := would be used so often that it should be part of the language/standard library.

Would you please justify this? Would you please answer the questions from my reply?

See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290

···

On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com> wrote:

Stephen

13

See what part? This document provides no justification for any kind of assignment/assertion operator. Please provide additional context around links you share and how they relate to your actual proposal.

In this case your proposal still needs justification. Would you, again, please answer these questions to provide it?

- Why do you want this feature?

- Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?

- Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?

···

On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com> wrote:

On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com> wrote:

I think this := would be used so often that it should be part of the language/standard library.

Would you please justify this? Would you please answer the questions from my reply?

See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290

--
Stephen

14

I think this := would be used so often that it should be part of the language/standard library.

Would you please justify this? Would you please answer the questions from my reply?

See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290

See what part? This document provides no justification for any kind of assignment/assertion operator. Please provide additional context around links you share and how they relate to your actual proposal.

The justification for assertions in general is empirical and the Microsoft paper provides it.

To explore how useful := assertions are in particular would need a study like the Microsoft one that focuses exclusively on := assertions.

···

On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com> wrote:

On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com> wrote:

In this case your proposal still needs justification. Would you, again, please answer these questions to provide it?

- Why do you want this feature?

- Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?

- Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?

--
Stephen

15

The justification for assertions in general is unnecessary. Swift already
has assertion functions: "assert" and "precondition" (even though it's
still not clear to me why we have two of them). This thread isn't about
software assertions.

This thread is about your := assertion operator. This thread *is* the
exploration of it, as it relates to Swift. You think it would be worth
including in Swift? Then argue its case. Tell us why := is useful. Provide
a code sample of one of the situations you think it would be used so often
for. Show us the value.

Don't expect us to do all the work here. Your suggestions lack sufficient
information to make their worth obvious to us. At the moment you're not
convincing us that you've thought about your proposal enough to even decide
if it was worth pitching, before you pitched it. Please make that effort.

···

On Sat, Feb 27, 2016 at 4:10 PM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

> On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis@gmail.com> > wrote:
>
>
>> On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com> wrote:
>>
>>> On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com> > wrote:
>>>
>>>> On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com> wrote:
>>>>
>>>> I think this := would be used so often that it should be part of the
language/standard library.
>>>
>>> Would you please justify this? Would you please answer the questions
from my reply?
>>
>> See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290
>
> See what part? This document provides no justification for any kind of
assignment/assertion operator. Please provide additional context around
links you share and how they relate to your actual proposal.

The justification for assertions in general is empirical and the Microsoft
paper provides it.

To explore how useful := assertions are in particular would need a study
like the Microsoft one that focuses exclusively on := assertions.

>
> In this case your proposal still needs justification. Would you, again,
please answer these questions to provide it?
>
> - Why do you want this feature?
>
> - Would you please provide a better, real-world example (perhaps code
extracted from a real-world project you've worked on that would benefit)
that demonstrates the benefits of your suggestion?
>
> - Can you go into more detail on the the design of the proposal? How it
may be implemented? Caveats? Alternatives considered?
>
> --
> Stephen

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

16

I am confused. This is a magical operator that does two things…. if it is a very special case of nil before then it asserts - but if it does not it assigns?

I would think you would simply do an assert (condition) and potentially an error text.

nil / nul exceptions (java experience) makes up more than 50% of defects (due to the original lack of optionals), but the that is what the optional in Swift is suppose to take care of through a the type system.

nil is actually not “nil” in the traditional sense but “None” as in the optional of it.

···

On 2016-02-27, at 23:10:37, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com> wrote:

On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com> wrote:

I think this := would be used so often that it should be part of the language/standard library.

Would you please justify this? Would you please answer the questions from my reply?

See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290

See what part? This document provides no justification for any kind of assignment/assertion operator. Please provide additional context around links you share and how they relate to your actual proposal.

The justification for assertions in general is empirical and the Microsoft paper provides it.

To explore how useful := assertions are in particular would need a study like the Microsoft one that focuses exclusively on := assertions.

In this case your proposal still needs justification. Would you, again, please answer these questions to provide it?

- Why do you want this feature?

- Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?

- Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?

--
Stephen

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

17

The justification for assertions in general is unnecessary. Swift already has assertion functions: "assert" and "precondition" (even though it's still not clear to me why we have two of them). This thread isn't about software assertions.

This thread is about your := assertion operator. This thread *is* the exploration of it, as it relates to Swift. You think it would be worth including in Swift? Then argue its case. Tell us why := is useful. Provide a code sample of one of the situations you think it would be used so often for. Show us the value.

Again, this would require an empirical study like the Microsoft one. You can’t argue your way through it.

···

On Feb 27, 2016, at 11:19 AM, Ross O'Brien <narrativium@gmail.com> wrote:

Don't expect us to do all the work here. Your suggestions lack sufficient information to make their worth obvious to us. At the moment you're not convincing us that you've thought about your proposal enough to even decide if it was worth pitching, before you pitched it. Please make that effort.

On Sat, Feb 27, 2016 at 4:10 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
>
>
>> On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
>>
>>> On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
>>>
>>>> On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
>>>>
>>>> I think this := would be used so often that it should be part of the language/standard library.
>>>
>>> Would you please justify this? Would you please answer the questions from my reply?
>>
>> See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290 <http://research.microsoft.com/apps/pubs/default.aspx?id=70290&gt;
>
> See what part? This document provides no justification for any kind of assignment/assertion operator. Please provide additional context around links you share and how they relate to your actual proposal.

The justification for assertions in general is empirical and the Microsoft paper provides it.

To explore how useful := assertions are in particular would need a study like the Microsoft one that focuses exclusively on := assertions.

>
> In this case your proposal still needs justification. Would you, again, please answer these questions to provide it?
>
> - Why do you want this feature?
>
> - Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?
>
> - Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?
>
> --
> Stephen

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

18

But if you were to provide a reasonably thorough argument for proposing it here it could be taken more seriously.

My earlier (repeated) questions were my attempt of better understanding exactly what is driving your motivation behind the proposal. Are you evading them for a reason? I would like to actually give a careful consideration of your proposals in the future, but without carefully answering these questions I find it difficult to give them fair evaluations

So, let's try this again:

- Why do you want this feature?

- Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?

- Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?

···

On Feb 27, 2016, at 11:21 AM, Amir Michail <a.michail@me.com> wrote:

On Feb 27, 2016, at 11:19 AM, Ross O'Brien <narrativium@gmail.com> wrote:

The justification for assertions in general is unnecessary. Swift already has assertion functions: "assert" and "precondition" (even though it's still not clear to me why we have two of them). This thread isn't about software assertions.

This thread is about your := assertion operator. This thread *is* the exploration of it, as it relates to Swift. You think it would be worth including in Swift? Then argue its case. Tell us why := is useful. Provide a code sample of one of the situations you think it would be used so often for. Show us the value.

Again, this would require an empirical study like the Microsoft one. You can’t argue your way through it.

--
Stephen

19

Microsofts study is based on C# (no personal hand’s on experience myself) which was modeled after Java.

As far as I can tell from the code example in the document - it looks like it made the mistake with “null” that Java did (a hole in the type system).

nil in Swift is actually None for optional types - which were a type-safe way of dealing of situations like this.

Which in that case would make the study meaningless since some of the base assumptions do not apply in Swift.

Which comes back to what a few people are asking for … examples, situations where Swift would have a problem that would need this addition.

···

On 2016-02-27, at 23:21:08, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 27, 2016, at 11:19 AM, Ross O'Brien <narrativium@gmail.com <mailto:narrativium@gmail.com>> wrote:

The justification for assertions in general is unnecessary. Swift already has assertion functions: "assert" and "precondition" (even though it's still not clear to me why we have two of them). This thread isn't about software assertions.

This thread is about your := assertion operator. This thread *is* the exploration of it, as it relates to Swift. You think it would be worth including in Swift? Then argue its case. Tell us why := is useful. Provide a code sample of one of the situations you think it would be used so often for. Show us the value.

Again, this would require an empirical study like the Microsoft one. You can’t argue your way through it.

Don't expect us to do all the work here. Your suggestions lack sufficient information to make their worth obvious to us. At the moment you're not convincing us that you've thought about your proposal enough to even decide if it was worth pitching, before you pitched it. Please make that effort.

On Sat, Feb 27, 2016 at 4:10 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
>
>
>> On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
>>
>>> On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
>>>
>>>> On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
>>>>
>>>> I think this := would be used so often that it should be part of the language/standard library.
>>>
>>> Would you please justify this? Would you please answer the questions from my reply?
>>
>> See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290 <http://research.microsoft.com/apps/pubs/default.aspx?id=70290&gt;
>
> See what part? This document provides no justification for any kind of assignment/assertion operator. Please provide additional context around links you share and how they relate to your actual proposal.

The justification for assertions in general is empirical and the Microsoft paper provides it.

To explore how useful := assertions are in particular would need a study like the Microsoft one that focuses exclusively on := assertions.

>
> In this case your proposal still needs justification. Would you, again, please answer these questions to provide it?
>
> - Why do you want this feature?
>
> - Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?
>
> - Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?
>
> --
> Stephen

_______________________________________________
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

20

Microsofts study is based on C# (no personal hand’s on experience myself) which was modeled after Java.

As far as I can tell from the code example in the document - it looks like it made the mistake with “null” that Java did (a hole in the type system).

nil in Swift is actually None for optional types - which were a type-safe way of dealing of situations like this.

Which in that case would make the study meaningless since some of the base assumptions do not apply in Swift.

Which comes back to what a few people are asking for … examples, situations where Swift would have a problem that would need this addition.

It’s a convenience feature that saves lots of finger typing.

Which would you rather have:

precondition( x == nil )
x = 3

OR

x: = 3

?

···

On Feb 27, 2016, at 11:26 AM, Craig Cruden <ccruden@novafore.com> wrote:

On 2016-02-27, at 23:21:08, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 27, 2016, at 11:19 AM, Ross O'Brien <narrativium@gmail.com <mailto:narrativium@gmail.com>> wrote:

The justification for assertions in general is unnecessary. Swift already has assertion functions: "assert" and "precondition" (even though it's still not clear to me why we have two of them). This thread isn't about software assertions.

This thread is about your := assertion operator. This thread *is* the exploration of it, as it relates to Swift. You think it would be worth including in Swift? Then argue its case. Tell us why := is useful. Provide a code sample of one of the situations you think it would be used so often for. Show us the value.

Again, this would require an empirical study like the Microsoft one. You can’t argue your way through it.

Don't expect us to do all the work here. Your suggestions lack sufficient information to make their worth obvious to us. At the moment you're not convincing us that you've thought about your proposal enough to even decide if it was worth pitching, before you pitched it. Please make that effort.

On Sat, Feb 27, 2016 at 4:10 PM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
>
>
>> On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
>>
>>> On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis@gmail.com <mailto:stephen.celis@gmail.com>> wrote:
>>>
>>>> On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> wrote:
>>>>
>>>> I think this := would be used so often that it should be part of the language/standard library.
>>>
>>> Would you please justify this? Would you please answer the questions from my reply?
>>
>> See: http://research.microsoft.com/apps/pubs/default.aspx?id=70290 <http://research.microsoft.com/apps/pubs/default.aspx?id=70290&gt;
>
> See what part? This document provides no justification for any kind of assignment/assertion operator. Please provide additional context around links you share and how they relate to your actual proposal.

The justification for assertions in general is empirical and the Microsoft paper provides it.

To explore how useful := assertions are in particular would need a study like the Microsoft one that focuses exclusively on := assertions.

>
> In this case your proposal still needs justification. Would you, again, please answer these questions to provide it?
>
> - Why do you want this feature?
>
> - Would you please provide a better, real-world example (perhaps code extracted from a real-world project you've worked on that would benefit) that demonstrates the benefits of your suggestion?
>
> - Can you go into more detail on the the design of the proposal? How it may be implemented? Caveats? Alternatives considered?
>
> --
> Stephen

_______________________________________________
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