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

Thorsten Seitz tseitz42 at icloud.com
Fri Jan 8 07:28:23 CST 2016 

> Am 08.01.2016 um 12:58 schrieb Rafael Costa <rafael at rafaelcosta.me>:
> 
> Completely opposed to this change. Optional a are there and already fill this gap. Also, as to "capturing the programmers intent", I completely disagree: As said by someone here: there's no "uninitialised" state. It is always "initialised to nil".

Sorry, if I didn’t express myself well enough: for optional values that is correct (i.e. values that are allowed to be missing by your business logic). 

In cases of delayed initialization for mandatory values (which are *not* allowed to be missing by your business logic), though, there definitely *is* an uninitialized state which lasts until the delayed initialization did happen. 
When modelling this with an IUO this uninitialized state is expressed by nil which will raise an exception if accessed and rightfully so, because your business logic does not expect this.

The problems with IUO are 
(1) they can be reset to nil which does not make sense IMO and 
(2) they confuse nil == missing optional value with nil == uninitialized mandatory value. These are two completely different meanings and it is unfortunate that they are both expressed by nil, similar to the problem of null in Java (with the big improvement in Swift that the types and the behaviors differ :-).

For the record: As we currently do not (yet) have a clean way of expressing delayed initialization, I don’t think we should introduce „none“ now. 
Getting rid of the problems with IUOs should be part of a proposal defining delayed initialization (and it has to be seen whether „none“ would be part of that or if there aren’t other solutions).

-Thorsten


> 
> Rafael Costa
> Envoyé de mon iPhone
> 
> Le 8 janv. 2016 à 07:50, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
> 
>> type T always means a value of T
>> type T? always means an *optional* value of T, i.e. it is part of the business logic that the value can be missing (i.e. is nil)
>> type T! always means delayed initialization, i.e. the value is not optional and business logic never assumes nil
>> 
>> This is an important distinction! Languages like Java typically use(d) null for both latter cases, mixing them up. 
>> Using IUOs for the latter case is more clear but still unfortunate as the value nil is still mixing both cases up and leading to confusion.
>> 
>> I think that confusion is what Amir wants to clean up.
>> The point of his proposal is to make clear that a value of nil is always ok for business logic because the new value of none takes the other role.
>> 
>> We could keep the type notation T! as is but it would no longer be an IUO allowing assignment of nil but would start out with a value of none (or should be explicitly initialized with that). I’d expect that assignment of none would not be allowed, i.e. falling back to the uninitialized state would be prohibited (another distinction from IOUs).
>> This might be part of a proposal targeting delayed initialization.
>> 
>> -Thorsten
>> 
>>> Am 08.01.2016 um 01:19 schrieb Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>> 
>>>> 
>>>> On Jan 7, 2016, at 7:09 PM, Jack Lawrence <jackl at apple.com <mailto:jackl at apple.com>> wrote:
>>>> 
>>>>> Currently, “nil” can mean either “uninitialized” or “initialized to nil”, which can be confusing. What I propose is cleaner and eliminates the need for implicitly unwrapped optionals.
>>>> 
>>>> `nil` always means “initialized to nil”. It never means “uninitialized”.
>>> 
>>> The point is that “nil" doesn’t capture the programmer’s intent precisely. The intent could be to delay initialization (e.g., until viewDidLoad) or it could be to use nil as a special value (e.g., to indicate the end of a linked list).
>>> 
>>>> 
>>>>> As I mentioned elsewhere, you could still use “!” in the type to indicate a variable that may be uninitialized but is not necessarily an optional, thus separating the concepts of uninitialized from “initialized to nil”.
>>>> 
>>>> I’d be interested to see a real world code example where this language change is useful and as safe or safer than Optional/IUO.
>>>> 
>>>> Jack
>>>> 
>>>>> On Jan 7, 2016, at 4:03 PM, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 7, 2016, at 6:58 PM, Jarod Long <swift at lng.la <mailto:swift at lng.la>> wrote:
>>>>>> 
>>>>>> The problem as I see it is that the functionality of none is already covered by optionals in a safer way. If something might be uninitialized, it really should be made explicit to the programmer so that they know to handle it properly. Implicitly-unwrapped optionals are already pretty generous in terms of allowing the programmer to ignore the possibility of a nil value, so it seems unnecessary to create a new feature to make it even easier.
>>>>>> 
>>>>> 
>>>>> Currently, “nil” can mean either “uninitialized” or “initialized to nil”, which can be confusing. What I propose is cleaner and eliminates the need for implicitly unwrapped optionals.
>>>>> 
>>>>> As I mentioned elsewhere, you could still use “!” in the type to indicate a variable that may be uninitialized but is not necessarily an optional, thus separating the concepts of uninitialized from “initialized to nil”.
>>>>> 
>>>>>> Jarod
>>>>>> 
>>>>>> 
>>>>>> On Jan 7, 2016, 15:44 -0800, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>>, wrote:
>>>>>>> 
>>>>>>>> On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd at lng.la <mailto: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>
>>>>>>> 
>>>>> 
>>>>>  _______________________________________________
>>>>> 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>
>> 
>> _______________________________________________
>> 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/20160108/c7df9c6f/attachment.html>

More information about the swift-evolution mailing list