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

[James Campbell]

Its worth mentioning that in some languages such as "!" is used to denote a
potentially dangerous operation, so the existing system I feel is fine :)

On Thu, Jan 7, 2016 at 11:53 PM, Austin Zheng via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/e04f88e8/attachment.html>