[swift-evolution] Proposal: Add "none" and simplify the language.

[Amir Michail]

> On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd at lng.la> wrote:
> 
> None is really just another way of saying something is nil, and a type suffix to allow assigning none is exactly equivalent to implicitly-unwrapped optionals, so I don't see any value in replacing them with this feature.

“None" means a variable is uninitialized. “Nil" need not mean that.

Reading an uninitialized variable is an error. Reading a nil variable need not be.

With “none", you can have uninitialized variables without resorting to optionals or implicitly unwrapped optionals.

> 
> Not requiring a type suffix to assign none would be equivalent to allowing assignment of nil to any type, making everything an implicitly-unwrapped optional. You lose the compile-time nil safety that optionals provide, and the compiler likely loses many optimization opportunities because there are many situations where it can't know (or it is very difficult to know) whether a value could have possibly been assigned none at some point.
> 
> I understand the desire to reduce optionality to make code cleaner, but this kind of feature actually hides complexity and makes things more difficult in the long run. Implicitly-unwrapped optionals are a good compromise between cleanliness and effectively communicating when something can fail at run time.
> 
> Jarod
> 
>> On Jan 7, 2016, at 11:41, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>> 
>>> Yes, but following your suggestion, there may not be a difference between a non-optional value and an implicitly-wrapped optional, meaning that there will be a lot more of them.
>> 
>> Variables that are never assigned "none" need not have these runtime checks. Alternatively, you can have a type suffix similar to ? to indicate that a variable may be in an uninitialized state. 
>> 
>>> 
>>> Félix
>>> 
>>>> Le 7 janv. 2016 à 14:10:44, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>> a écrit :
>>>> 
>>>> 
>>>>> On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>>>>> 
>>>>> That would leave you with runtime checks instead of compile-time checks and I totally disagree with that.
>>>>> 
>>>> 
>>>> Implicitly unwrapped optionals do runtime checks also.
>>>> 
>>>>> Félix
>>>>> 
>>>>>> Le 7 janv. 2016 à 13:45:21, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>> a écrit :
>>>>>> 
>>>>>> 
>>>>>>> On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>>>>>>> 
>>>>>>> An implicitly-unwrapped optional would do almost that, no?
>>>>>>> 
>>>>>> 
>>>>>> You can use “none” to eliminate implicitly unwrapped optionals from the language.
>>>>>> 
>>>>>>> Félix
>>>>>>> 
>>>>>>>> Le 7 janv. 2016 à 12:46:53, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>>>>>> 
>>>>>>>> Examples:
>>>>>>>> 
>>>>>>>> var x:Int = none // uninitialized but not an optional
>>>>>>>> 
>>>>>>>> print(x) // run-time error as x is uninitialized
>>>>>>>> 
>>>>>>>> if x == nil { … } // compile time error… x can never be nil because it is not an optional
>>>>>>>> 
>>>>>>>> if x == none { x = 2 } // … but it can be uninitialized
>>>>>>>> 
>>>>>>>> Optionals can also be uninitialized:
>>>>>>>> 
>>>>>>>> var y:Int? = none // uninitialized and an optional
>>>>>>>> 
>>>>>>>> if y == nil { … } // run-time error as y is uninitialized
>>>>>>>> 
>>>>>>>> y = nil
>>>>>>>> 
>>>>>>>> if y == nil { … } // fine
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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 <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/d3693778/attachment-0001.html>