[swift-evolution] mandatory "?" suffix for identifiers associated with optional types

[Adrian Kashivskyy]

I agree with Alex, 

> Optionality is associated with the type, not the identifier.

Optionals are designed to provide null safety inside a program, not promote using nullables wherever possible. If you use optionals so extensively that you feel the need for special IDE support, maybe you should consider rethinking your API.

By the way,

> So for example the following (probable) bug would result in a compile error:
> let f = x < 5 // where x is optional and could be nil

I believe nil being less than anything else is an expected behavior which has been introduced by design.

Pozdrawiam – Regards,
Adrian Kashivskyy

> Wiadomość napisana przez Amir Michail <a.michail at me.com> w dniu 04.12.2015, o godz. 17:17:
> 
>> 
>> On Dec 4, 2015, at 10:57 AM, Alex Blewitt <alex.blewitt at gmail.com <mailto:alex.blewitt at gmail.com>> wrote:
>> 
>> 
>>> On 4 Dec 2015, at 16:44, Amir Michail <a.michail at me.com <mailto:a.michail at me.com>> wrote:
>>> 
>>> I don’t want to remember if a variable is optional. I want to see it in the variable name.
>> 
>> Optionality is associated with the type, not the identifier. In addition, how would you deal with type aliases to optional constructs?
>> 
>> typealias MaybeString = String?
>> var maybe:MaybeString
>> 
>> This doesn’t ‘look’ like an optional value (so would it deserve a ? at the end) but if you have MaybeString? you now have an Optional<Optional<String>>. Should you have ?? there now?
>> 
>> Alex
> 
> You would have:
> 
> typealias MaybeString? = String?
> var maybe?:MaybeString?
> 
>  _______________________________________________
> 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/20151204/be8e8c99/attachment.html>