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

[Austin Zheng]

So we go from knowing that variables are never accessed in an uninitialized
state at compile-time (because the compiler checks for us), to not knowing
if a variable is uninitialized at runtime until we check for 'none'? If I
wanted a variable that could be uninitialized I would prefer to use an IUO;
that way at least I can see the '!' in the type definition and be aware
that I need to check for nil before I can properly use the variable if
needed.

More generally, I am strongly against turning compile-time checks into
runtime checks unless there's a compelling reason.

Austin

On Thu, Jan 7, 2016 at 3:44 PM, Amir Michail via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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> wrote:
>
>
>
> Sent from my iPad
>
> On Jan 7, 2016, at 2:34 PM, Félix Cloutier <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> a écrit :
>
>
> On Jan 7, 2016, at 2:09 PM, Félix Cloutier <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> a écrit :
>
>
> On Jan 7, 2016, at 1:40 PM, Félix Cloutier <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> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> 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/20160107/200a01a7/attachment.html>