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

Thu Jan 7 18:43:21 CST 2016

I am completely opposed to this change. We don't need a runtime checked
nothing value.  It is simple to explain that the default value of an
optional is nil.

On Thu, Jan 7, 2016 at 7:39 PM, Jack Lawrence via swift-evolution <
swift-evolution at swift.org> wrote:

> I’m not sure I see how “none”–or the bifurcation it creates–captures
> intent any more clearly than “nil".
>
> Jack
>
> On Jan 7, 2016, at 4:19 PM, Amir Michail <a.michail at me.com> wrote:
>
>
> On Jan 7, 2016, at 7:09 PM, Jack Lawrence <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> wrote:
>
>
> On Jan 7, 2016, at 6:58 PM, Jarod Long <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>, 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
>
>
>
>
>
> _______________________________________________
> 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/85145ab0/attachment.html>