Proposal: Add "none" and simplify the language.

Evolution Discussion
1

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

2

This use case should be supportable as a property behavior; check out the "delayed" example from my proposal:

-Joe

···

On Jan 7, 2016, at 9:46 AM, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

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

3

An implicitly-unwrapped optional would do almost that, no?

Félix

···

Le 7 janv. 2016 à 12:46:53, Amir Michail via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

So what would none do for arrays ?

Would it auto initialize an empty array ?

If so would love to play around with alternative key words

···

On Thu, Jan 7, 2016 at 5:50 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

> On Jan 7, 2016, at 9:46 AM, Amir Michail via swift-evolution < > swift-evolution@swift.org> wrote:
>
> 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

This use case should be supportable as a property behavior; check out the
"delayed" example from my proposal:

Swift property behaviors · GitHub

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

5

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

I think there *may* be a case for this as a strictly static check. That is, setting a variable to `none` would be a way to explicitly mark the current state as invalid, and ask the compiler to prove that it's not used again until you've reinitialized it. But your example of `x == none` would not make any sense—`none` would not be a thing that existed at runtime. That's a very niche feature, though, and I'd need convincing that it's helpful.

I'm strongly opposed to this feature as a runtime construct. It's basically just reintroducing null references, which is an anti-goal.

···

--
Brent Royal-Gordon
Architechies

6

So what would none do for arrays ?

Would it auto initialize an empty array ?

If so would love to play around with alternative key words

If I understand Amir correctly, they're proposing that 'none' place the variable in a dynamically invalid state, and the program will trap if the value isn't set before use.

-Joe

···

On Jan 7, 2016, at 9:56 AM, James Campbell <james@supmenow.com> wrote:

On Thu, Jan 7, 2016 at 5:50 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 7, 2016, at 9:46 AM, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> 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

This use case should be supportable as a property behavior; check out the "delayed" example from my proposal:

Swift property behaviors · GitHub

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com <mailto:james@supmenow.com>
+44 7523 279 698

7

An implicitly-unwrapped optional would do almost that, no?

You can use “none” to eliminate implicitly unwrapped optionals from the language.

···

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:

Félix

Le 7 janv. 2016 à 12:46:53, Amir Michail via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

8

To have ? in the symbol is much better than looking back again and again to
ensure variable is initialized or not for me.

Ruby style of fields naming is even better for reading, though a little
burden for writing.

···

On Sat, Jan 9, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> 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

I think there *may* be a case for this as a strictly static check. That
is, setting a variable to `none` would be a way to explicitly mark the
current state as invalid, and ask the compiler to prove that it's not used
again until you've reinitialized it. But your example of `x == none` would
not make any sense—`none` would not be a thing that existed at runtime.
That's a very niche feature, though, and I'd need convincing that it's
helpful.

I'm strongly opposed to this feature as a runtime construct. It's
basically just reintroducing null references, which is an anti-goal.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Best Regards!

Yang Wu
--------------------------------------------------------
Location: Pudong, Shanghai, China.
EMail : pinxue@gmail.com
Website: http://www.time2change.mobi http://rockplayer.com
Twitter/Weibo : @pinxue
<http://www.pinxue.net>

9

That would leave you with runtime checks instead of compile-time checks and I totally disagree with that.

Félix

···

Le 7 janv. 2016 à 13:45:21, Amir Michail <a.michail@me.com> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

10

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.

···

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:

Félix

Le 7 janv. 2016 à 13:45:21, Amir Michail <a.michail@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

11

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.

Félix

···

Le 7 janv. 2016 à 14:10:44, Amir Michail <a.michail@me.com> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

12

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.

···

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:

Félix

Le 7 janv. 2016 à 14:10:44, Amir Michail <a.michail@me.com> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@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@me.com> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

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.

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, 11:41 -0800, Amir Michail via swift-evolution<swift-evolution@swift.org>, wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier<felixcca@yahoo.ca(mailto:felixcca@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@me.com(mailto:a.michail@me.com)>a écrit :
> >
> > > On Jan 7, 2016, at 2:09 PM, Félix Cloutier<felixcca@yahoo.ca(mailto:felixcca@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@me.com(mailto:a.michail@me.com)>a écrit :
> > > >
> > > > > On Jan 7, 2016, at 1:40 PM, Félix Cloutier<felixcca@yahoo.ca(mailto:felixcca@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@swift.org(mailto:swift-evolution@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@swift.org(mailto:swift-evolution@swift.org)
> > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > >
> > > >
> > >
> >
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

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.

···

On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd@lng.la> wrote:

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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

15

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@swift.org> wrote:

On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd@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@swift.org> wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@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@me.com> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@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@me.com> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

16

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.

Jarod

···

On Jan 7, 2016, 15:44 -0800, Amir Michail<a.michail@me.com>, wrote:

> On Jan 7, 2016, at 3:15 PM, Jarod Long<jrd@lng.la(mailto:jrd@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@swift.org(mailto:swift-evolution@swift.org)>wrote:
> >
> >
> > Sent from my iPad
> >
> > On Jan 7, 2016, at 2:34 PM, Félix Cloutier<felixcca@yahoo.ca(mailto:felixcca@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@me.com(mailto:a.michail@me.com)>a écrit :
> > > >
> > > > > On Jan 7, 2016, at 2:09 PM, Félix Cloutier<felixcca@yahoo.ca(mailto:felixcca@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@me.com(mailto:a.michail@me.com)>a écrit :
> > > > > >
> > > > > > > On Jan 7, 2016, at 1:40 PM, Félix Cloutier<felixcca@yahoo.ca(mailto:felixcca@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@swift.org(mailto:swift-evolution@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@swift.org(mailto:swift-evolution@swift.org)
> > > > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution

17

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.

You could still use “!” in the type definition to indicate a variable that may be uninitialized at various points. Such a variable need not be an optional but it could be. None and nil are different things.

···

On Jan 7, 2016, at 6:53 PM, Austin Zheng <austinzheng@gmail.com> wrote:

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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd@lng.la <mailto:jrd@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

18

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”.

···

On Jan 7, 2016, at 6:58 PM, Jarod Long <swift@lng.la> wrote:

Jarod

On Jan 7, 2016, 15:44 -0800, Amir Michail <a.michail@me.com>, wrote:

On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd@lng.la <mailto:jrd@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

19

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@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@swift.org> wrote:

On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd@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@swift.org> wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@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@me.com> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@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@me.com> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

20

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”.

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@swift.org> wrote:

On Jan 7, 2016, at 6:58 PM, Jarod Long <swift@lng.la <mailto:swift@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@me.com <mailto:a.michail@me.com>>, wrote:

On Jan 7, 2016, at 3:15 PM, Jarod Long <jrd@lng.la <mailto:jrd@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPad

On Jan 7, 2016, at 2:34 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 2:09 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@me.com <mailto:a.michail@me.com>> a écrit :

On Jan 7, 2016, at 1:40 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution