[swift-evolution] Proposal: An assignment operator := that ensures nil before assignment.

[Amir Michail]

> On Feb 27, 2016, at 11:26 AM, Craig Cruden <ccruden at novafore.com> wrote:
> 
> 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 2016-02-27, at 23:21:08, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Feb 27, 2016, at 11:19 AM, Ross O'Brien <narrativium at gmail.com <mailto:narrativium at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> > On Feb 27, 2016, at 11:07 AM, Stephen Celis <stephen.celis at gmail.com <mailto:stephen.celis at gmail.com>> wrote:
>>> >
>>> >
>>> >> On Feb 27, 2016, at 10:57 AM, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>> wrote:
>>> >>
>>> >>> On Feb 27, 2016, at 10:39 AM, Stephen Celis <stephen.celis at gmail.com <mailto:stephen.celis at gmail.com>> wrote:
>>> >>>
>>> >>>> On Feb 27, 2016, at 10:38 AM, Amir Michail <a.michail at me.com <mailto:a.michail at 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>
>>> >
>>> > 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/286c94f2/attachment.html>