Discussion: Why is "nil" not "none"


(Brandon Knope) #1

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon


(Jordan Rose) #2

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for Objective-C, but that doesn’t make it an invalid choice. There are lots of things in Swift we might have done differently if it weren’t for Objective-C and Cocoa.

Jordan

···

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brandon Knope) #3

I guess for me it comes down to this:

Why were some and none chosen for as the cases for Optional?

As an extension of that, why does nil then represent none instead of the obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I thought it was worth opening up a discussion about possibly changing direction a little here.

Thanks,
Brandon

···

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for Objective-C, but that doesn’t make it an invalid choice. There are lots of things in Swift we might have done differently if it weren’t for Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Saagar Jha) #4

Well, some is the opposite of none in that if I don’t have some, I have
none. nil is just a carry-over from Objective-C.

···

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote:

I guess for me it comes down to this:

*Why were some and none chosen for as the cases for Optional?*

As an extension of that, why does nil then represent none instead of the
obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I
thought it was worth opening up a discussion about possibly changing
direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re
dwindling now that pointer nullability is represented by Optional. That
said, I’m not convinced renaming “nil” is worth it at this point.
Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for
Objective-C, but that doesn’t make it an invalid choice. There are lots of
things in Swift we might have done differently if it weren’t for
Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil
to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value
of nothing

1. It is more consistent with the optional enum

2. The intent is arguably clearer

3. nil makes it seem like it's a pointer

4. Would nil be included if not for prior languages? Would "none" have
been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none
is used, some syntactic sugar might make it look nicer than always having
the stray .

On vacation from Orlando, poolside, with a quick thought,

Brandon

_______________________________________________

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

--
-Saagar Jha


(Brandon Knope) #5

That's exactly the point I was going for.

none makes more sense in this context than nil in my opinion

Brandon

···

On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Well, some is the opposite of none in that if I don’t have some, I have none. nil is just a carry-over from Objective-C.

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
I guess for me it comes down to this:

Why were some and none chosen for as the cases for Optional?

As an extension of that, why does nil then represent none instead of the obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I thought it was worth opening up a discussion about possibly changing direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for Objective-C, but that doesn’t make it an invalid choice. There are lots of things in Swift we might have done differently if it weren’t for Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon
_______________________________________________
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

--
-Saagar Jha


#6

No clue as to the origins, but if you insist on using none. you can do:

let a : Int? = .none
let b : Int? = .some(5)

Using the simpler

let a : Int? = nil
let b : Int? = 5

is just sugar.
Maybe it was foresight to prevent people from saying, if I can do:

let a : Int? = none

Why can't I do:

let b : Int? = some(5)

And then go a step further by asking for all enum to be access without the leading dot; scary thought.

So it may be better to stick with '.none' and sugared 'nil'.

Dany

···

Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution <swift-evolution@swift.org> a écrit :

That's exactly the point I was going for.

none makes more sense in this context than nil in my opinion

Brandon

On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Well, some is the opposite of none in that if I don’t have some, I have none. nil is just a carry-over from Objective-C.

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
I guess for me it comes down to this:

Why were some and none chosen for as the cases for Optional?

As an extension of that, why does nil then represent none instead of the obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I thought it was worth opening up a discussion about possibly changing direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for Objective-C, but that doesn’t make it an invalid choice. There are lots of things in Swift we might have done differently if it weren’t for Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon
_______________________________________________
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

--
-Saagar Jha

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


(Saagar Jha) #7

That’s not quite what I meant. nil feels right to refer to an object-you
can say “Foo is nil”, but you can’t really say that “Foo is none”, since
while you can’t really use none as an adjective, as you can with nil. It’s
really about what flows right-none is the opposite of some, but nil isn’t.

···

On Tue, Jun 7, 2016 at 5:16 PM Brandon Knope <bknope@me.com> wrote:

That's exactly the point I was going for.

none makes more sense in this context than nil in my opinion

Brandon

On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Well, some is the opposite of none in that if I don’t have some, I have
none. nil is just a carry-over from Objective-C.

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote:

I guess for me it comes down to this:

*Why were some and none chosen for as the cases for Optional?*

As an extension of that, why does nil then represent none instead of the
obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I
thought it was worth opening up a discussion about possibly changing
direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re
dwindling now that pointer nullability is represented by Optional. That
said, I’m not convinced renaming “nil” is worth it at this point.
Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for
Objective-C, but that doesn’t make it an invalid choice. There are lots of
things in Swift we might have done differently if it weren’t for
Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution < >> swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename
nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a
value of nothing

1. It is more consistent with the optional enum

2. The intent is arguably clearer

3. nil makes it seem like it's a pointer

4. Would nil be included if not for prior languages? Would "none" have
been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common
nil/none is used, some syntactic sugar might make it look nicer than always
having the stray .

On vacation from Orlando, poolside, with a quick thought,

Brandon

_______________________________________________

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

--
-Saagar Jha

--

-Saagar Jha


(Muse M) #8

None would be similar to Null or nothing about the types in that sense
which None is not a type.
Nil would be interpret as Int, Float, String, etc

···

On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution < swift-evolution@swift.org> wrote:

No clue as to the origins, but if you insist on using none. you can do:

let a : Int? = .none
let b : Int? = .some(5)

Using the simpler

let a : Int? = nil
let b : Int? = 5

is just sugar.
Maybe it was foresight to prevent people from saying, if I can do:

let a : Int? = none

Why can't I do:

let b : Int? = some(5)

And then go a step further by asking for all enum to be access without the
leading dot; scary thought.

So it may be better to stick with '.none' and sugared 'nil'.

Dany

Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution < > swift-evolution@swift.org> a écrit :

That's exactly the point I was going for.

none makes more sense in this context than nil in my opinion

Brandon

On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Well, some is the opposite of none in that if I don’t have some, I have
none. nil is just a carry-over from Objective-C.

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote:

I guess for me it comes down to this:

*Why were some and none chosen for as the cases for Optional?*

As an extension of that, why does nil then represent none instead of the
obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I
thought it was worth opening up a discussion about possibly changing
direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re
dwindling now that pointer nullability is represented by Optional. That
said, I’m not convinced renaming “nil” is worth it at this point.
Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for
Objective-C, but that doesn’t make it an invalid choice. There are lots of
things in Swift we might have done differently if it weren’t for
Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution < >> swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename
nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a
value of nothing

1. It is more consistent with the optional enum

2. The intent is arguably clearer

3. nil makes it seem like it's a pointer

4. Would nil be included if not for prior languages? Would "none" have
been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common
nil/none is used, some syntactic sugar might make it look nicer than always
having the stray .

On vacation from Orlando, poolside, with a quick thought,

Brandon

_______________________________________________

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

--
-Saagar Jha

_______________________________________________
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


(Brandon Knope) #9

It depends how you frame it.

When I see nil I think of 0 or a pointer.

let someInt: Int? = nil

Does someInt really have a value of 0? Is it really a pointer (because it looks like one).

let someInt: Int? = none
let someInt: Int? = .none

- Doesn't look like a pointer and can't be mistaken as one
- indicates the value is none: it contains absolutely nothing

Another example: dictionaries

someDict[key] = nil
someDict[key] = none
someDict[key] = .none

To me this reads as the value for this key is none. It has no value.

I'm curious if "Foo is nil" reads better to you because it is what you/we are use to reading and not because it is actually better.

Also, it looks like Scala uses None for their option type so this isn't unprecedented.

Thanks,
Brandon

···

On Jun 7, 2016, at 8:30 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

That’s not quite what I meant. nil feels right to refer to an object-you can say “Foo is nil”, but you can’t really say that “Foo is none”, since while you can’t really use none as an adjective, as you can with nil. It’s really about what flows right-none is the opposite of some, but nil isn’t.

On Tue, Jun 7, 2016 at 5:16 PM Brandon Knope <bknope@me.com> wrote:
That's exactly the point I was going for.

none makes more sense in this context than nil in my opinion

Brandon

On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Well, some is the opposite of none in that if I don’t have some, I have none. nil is just a carry-over from Objective-C.

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
I guess for me it comes down to this:

Why were some and none chosen for as the cases for Optional?

As an extension of that, why does nil then represent none instead of the obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I thought it was worth opening up a discussion about possibly changing direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for Objective-C, but that doesn’t make it an invalid choice. There are lots of things in Swift we might have done differently if it weren’t for Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon
_______________________________________________
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

--
-Saagar Jha

--
-Saagar Jha


(J Charles N. M.) #10

I'am not either for removing nil nor renaming it none, I think that they are conceptually different things.

This syntactic sugar brings unfortunately many things around. One fastidious thing is it multiple semantics: As null pointer. As none value.
I am personally not favorable for multiples semantics keywords.

Aside, if it come up to revisiting nil concept we should bring the other chimera (unit, Void, bottom type etc).

···

--
J. Charles

Le 8 juin 2016 à 04:18, Muse M via swift-evolution <swift-evolution@swift.org> a écrit :

None would be similar to Null or nothing about the types in that sense which None is not a type.
Nil would be interpret as Int, Float, String, etc

On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:
No clue as to the origins, but if you insist on using none. you can do:

let a : Int? = .none
let b : Int? = .some(5)

Using the simpler

let a : Int? = nil
let b : Int? = 5

is just sugar.
Maybe it was foresight to prevent people from saying, if I can do:

let a : Int? = none

Why can't I do:

let b : Int? = some(5)

And then go a step further by asking for all enum to be access without the leading dot; scary thought.

So it may be better to stick with '.none' and sugared 'nil'.

Dany

Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution <swift-evolution@swift.org> a écrit :

That's exactly the point I was going for.

none makes more sense in this context than nil in my opinion

Brandon

On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Well, some is the opposite of none in that if I don’t have some, I have none. nil is just a carry-over from Objective-C.

On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
I guess for me it comes down to this:

Why were some and none chosen for as the cases for Optional?

As an extension of that, why does nil then represent none instead of the obvious none?

There has to be a reason why it's not:

enum Optional<T> {
case some(T)
case nil
}

None seems a lot more expressive and consistent with Optional.

I am comfortable and use to nil, but with swift being a new language, I thought it was worth opening up a discussion about possibly changing direction a little here.

Thanks,
Brandon

On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com> wrote:

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing.

It’s true that we might not have picked nil if it hadn’t been for Objective-C, but that doesn’t make it an invalid choice. There are lots of things in Swift we might have done differently if it weren’t for Objective-C and Cocoa.

Jordan

On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Quick thought:

If optional has a .none case, wouldn't it be more consistent to rename nil to none?

Also, would nil make it into Swift if not for other languages?

It also might make it somewhat clearer:

var someInt: Int? = none //looks less like a pointer and more like a value of nothing

1. It is more consistent with the optional enum
2. The intent is arguably clearer
3. nil makes it seem like it's a pointer
4. Would nil be included if not for prior languages? Would "none" have been chosen as the keyword if nil wasn't prior art?

One disadvantage is how close it is to .none, but with how common nil/none is used, some syntactic sugar might make it look nicer than always having the stray .

On vacation from Orlando, poolside, with a quick thought,
Brandon
_______________________________________________
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

--
-Saagar Jha

_______________________________________________
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


(Vladimir) #11

Reading the thread.. I wonder if we need "nil" at all, why not use (just a question, not a suggestion) .none ? I.e. now we can use nil and .none in the same situations, .none is just 2 symbols longer, '.none' highlight that Optional is a special type (that there is .some(T) in Optional), no confusion if it is related to pointers etc.

var i : Int? = 10
if i != .none { print(i) }
i = .none
print(i)

var i : Int? = 10
if i != nil { print(i) }
i = nil
print(i)

i.e. the same thing expressed in 2 different but similar ways. Probably I'm missing something.

···

On 08.06.2016 12:33, J. Charles M. N. via swift-evolution wrote:

I'am not either for removing nil nor renaming it none, I think that they
are conceptually different things.

This syntactic sugar brings unfortunately many things around. One
fastidious thing is it multiple semantics: As null pointer. As none value.
I am personally not favorable for multiples semantics keywords.

Aside, if it come up to revisiting nil concept we should bring the other
chimera (unit, Void, bottom type etc).

--
J. Charles

Le 8 juin 2016 à 04:18, Muse M via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

None would be similar to Null or nothing about the types in that sense
which None is not a type.
Nil would be interpret as Int, Float, String, etc

On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    No clue as to the origins, but if you insist on using none. you can do:

    let a : Int? = .none
    let b : Int? = .some(5)

    Using the simpler

    let a : Int? = nil
    let b : Int? = 5

    is just sugar.
    Maybe it was foresight to prevent people from saying, if I can do:

    let a : Int? = none

    Why can't I do:

    let b : Int? = some(5)

    And then go a step further by asking for all enum to be access
    without the leading dot; scary thought.

    So it may be better to stick with '.none' and sugared 'nil'.

    Dany

    Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

    That's exactly the point I was going for.

    none makes more sense in this context than nil in my opinion

    Brandon

    On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com >>> <mailto:saagarjha28@gmail.com>> wrote:

    Well, some is the opposite of none in that if I don’t have some, I
    have none. nil is just a carry-over from Objective-C.

    On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

        I guess for me it comes down to this:

        *Why were some and none chosen for as the cases for Optional?*

        As an extension of that, why does nil then represent none
        instead of the obvious none?

        There has to be a reason why it's not:

        enum Optional<T> {
        case some(T)
        case nil
        }

        None seems a lot more expressive and consistent with Optional.

        I am comfortable and use to nil, but with swift being a new
        language, I thought it was worth opening up a discussion about
        possibly changing direction a little here.

        Thanks,
        Brandon

        On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com >>>> <mailto:jordan_rose@apple.com>> wrote:

        There are NilLiteralConvertible types other than Optional, but
        they’re dwindling now that pointer nullability is represented
        by Optional. That said, I’m not convinced renaming “nil” is
        worth it at this point. Similarity with other languages is
        still a good thing.

        It’s true that we might not have picked nil if it hadn’t been
        for Objective-C, but that doesn’t make it an invalid choice.
        There are lots of things in Swift we might have done
        differently if it weren’t for Objective-C and Cocoa.

        Jordan

        On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution >>>>>> <swift-evolution@swift.org >>>>>> <mailto:swift-evolution@swift.org>> wrote:

        Quick thought:

        If optional has a .none case, wouldn't it be more consistent
        to rename nil to none?

        Also, would nil make it into Swift if not for other languages?

        It also might make it somewhat clearer:

        var someInt: Int? = none //looks less like a pointer and more
        like a value of nothing

        1. It is more consistent with the optional enum
        2. The intent is arguably clearer
        3. nil makes it seem like it's a pointer
        4. Would nil be included if not for prior languages? Would
        "none" have been chosen as the keyword if nil wasn't prior art?

        One disadvantage is how close it is to .none, but with how
        common nil/none is used, some syntactic sugar might make it
        look nicer than always having the stray .

        On vacation from Orlando, poolside, with a quick thought,
        Brandon
        _______________________________________________
        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

    --
    -Saagar Jha

    _______________________________________________
    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

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


(David Waite) #12

nil is not only usable with Optionals, although that is its most common usage.

Any type implementing NilLiteralConvertible can be initialized with a nil literal

-DW

···

On Jun 8, 2016, at 10:45 AM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

This is precisely the point I was trying to make.

“nil” is a holdover from other languages; i.e. we are comfortable with using it. I think there are better alternatives to consider.

However, when evaluating whether it makes sense with swift, I think it fails some of the criteria for inclusion.

My biggest bet why people are against .none is that the . looks noisy and unclean. This is why I am suggesting “none” as sugar for .none even though it might seem quite silly.

I also bet that 9 times out of 10, when people see nil they think of pointers and not optionals. Maybe this will take time to retrain ourselves to think optionality, but now nil is used for different things in different languages

Brandon

On Jun 8, 2016, at 10:56 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Reading the thread.. I wonder if we need "nil" at all, why not use (just a question, not a suggestion) .none ? I.e. now we can use nil and .none in the same situations, .none is just 2 symbols longer, '.none' highlight that Optional is a special type (that there is .some(T) in Optional), no confusion if it is related to pointers etc.

var i : Int? = 10
if i != .none { print(i) }
i = .none
print(i)

var i : Int? = 10
if i != nil { print(i) }
i = nil
print(i)

i.e. the same thing expressed in 2 different but similar ways. Probably I'm missing something.

On 08.06.2016 12:33, J. Charles M. N. via swift-evolution wrote:

I'am not either for removing nil nor renaming it none, I think that they
are conceptually different things.

This syntactic sugar brings unfortunately many things around. One
fastidious thing is it multiple semantics: As null pointer. As none value.
I am personally not favorable for multiples semantics keywords.

Aside, if it come up to revisiting nil concept we should bring the other
chimera (unit, Void, bottom type etc).

--
J. Charles

Le 8 juin 2016 à 04:18, Muse M via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> a écrit :

None would be similar to Null or nothing about the types in that sense
which None is not a type.
Nil would be interpret as Int, Float, String, etc

On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

   No clue as to the origins, but if you insist on using none. you can do:

   let a : Int? = .none
   let b : Int? = .some(5)

   Using the simpler

   let a : Int? = nil
   let b : Int? = 5

   is just sugar.
   Maybe it was foresight to prevent people from saying, if I can do:

   let a : Int? = none

   Why can't I do:

   let b : Int? = some(5)

   And then go a step further by asking for all enum to be access
   without the leading dot; scary thought.

   So it may be better to stick with '.none' and sugared 'nil'.

   Dany

   Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> a écrit :

   That's exactly the point I was going for.

   none makes more sense in this context than nil in my opinion

   Brandon

   On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com> >>>>> <mailto:saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>>> wrote:

   Well, some is the opposite of none in that if I don’t have some, I
   have none. nil is just a carry-over from Objective-C.

   On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

       I guess for me it comes down to this:

       *Why were some and none chosen for as the cases for Optional?*

       As an extension of that, why does nil then represent none
       instead of the obvious none?

       There has to be a reason why it's not:

       enum Optional<T> {
       case some(T)
       case nil
       }

       None seems a lot more expressive and consistent with Optional.

       I am comfortable and use to nil, but with swift being a new
       language, I thought it was worth opening up a discussion about
       possibly changing direction a little here.

       Thanks,
       Brandon

       On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com> >>>>>> <mailto:jordan_rose@apple.com <mailto:jordan_rose@apple.com>>> wrote:

       There are NilLiteralConvertible types other than Optional, but
       they’re dwindling now that pointer nullability is represented
       by Optional. That said, I’m not convinced renaming “nil” is
       worth it at this point. Similarity with other languages is
       still a good thing.

       It’s true that we might not have picked nil if it hadn’t been
       for Objective-C, but that doesn’t make it an invalid choice.
       There are lots of things in Swift we might have done
       differently if it weren’t for Objective-C and Cocoa.

       Jordan

       On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

       Quick thought:

       If optional has a .none case, wouldn't it be more consistent
       to rename nil to none?

       Also, would nil make it into Swift if not for other languages?

       It also might make it somewhat clearer:

       var someInt: Int? = none //looks less like a pointer and more
       like a value of nothing

       1. It is more consistent with the optional enum
       2. The intent is arguably clearer
       3. nil makes it seem like it's a pointer
       4. Would nil be included if not for prior languages? Would
       "none" have been chosen as the keyword if nil wasn't prior art?

       One disadvantage is how close it is to .none, but with how
       common nil/none is used, some syntactic sugar might make it
       look nicer than always having the stray .

       On vacation from Orlando, poolside, with a quick thought,
       Brandon
       _______________________________________________
       swift-evolution mailing list
       swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
       https://lists.swift.org/mailman/listinfo/swift-evolution

   --
   -Saagar Jha

   _______________________________________________
   swift-evolution mailing list
   swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto: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> <mailto: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

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


(Brandon Knope) #13

This is precisely the point I was trying to make.

“nil” is a holdover from other languages; i.e. we are comfortable with using it. I think there are better alternatives to consider.

However, when evaluating whether it makes sense with swift, I think it fails some of the criteria for inclusion.

My biggest bet why people are against .none is that the . looks noisy and unclean. This is why I am suggesting “none” as sugar for .none even though it might seem quite silly.

I also bet that 9 times out of 10, when people see nil they think of pointers and not optionals. Maybe this will take time to retrain ourselves to think optionality, but now nil is used for different things in different languages

Brandon

···

On Jun 8, 2016, at 10:56 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Reading the thread.. I wonder if we need "nil" at all, why not use (just a question, not a suggestion) .none ? I.e. now we can use nil and .none in the same situations, .none is just 2 symbols longer, '.none' highlight that Optional is a special type (that there is .some(T) in Optional), no confusion if it is related to pointers etc.

var i : Int? = 10
if i != .none { print(i) }
i = .none
print(i)

var i : Int? = 10
if i != nil { print(i) }
i = nil
print(i)

i.e. the same thing expressed in 2 different but similar ways. Probably I'm missing something.

On 08.06.2016 12:33, J. Charles M. N. via swift-evolution wrote:

I'am not either for removing nil nor renaming it none, I think that they
are conceptually different things.

This syntactic sugar brings unfortunately many things around. One
fastidious thing is it multiple semantics: As null pointer. As none value.
I am personally not favorable for multiples semantics keywords.

Aside, if it come up to revisiting nil concept we should bring the other
chimera (unit, Void, bottom type etc).

--
J. Charles

Le 8 juin 2016 à 04:18, Muse M via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> a écrit :

None would be similar to Null or nothing about the types in that sense
which None is not a type.
Nil would be interpret as Int, Float, String, etc

On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

   No clue as to the origins, but if you insist on using none. you can do:

   let a : Int? = .none
   let b : Int? = .some(5)

   Using the simpler

   let a : Int? = nil
   let b : Int? = 5

   is just sugar.
   Maybe it was foresight to prevent people from saying, if I can do:

   let a : Int? = none

   Why can't I do:

   let b : Int? = some(5)

   And then go a step further by asking for all enum to be access
   without the leading dot; scary thought.

   So it may be better to stick with '.none' and sugared 'nil'.

   Dany

   Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> a écrit :

   That's exactly the point I was going for.

   none makes more sense in this context than nil in my opinion

   Brandon

   On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com> >>>> <mailto:saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>>> wrote:

   Well, some is the opposite of none in that if I don’t have some, I
   have none. nil is just a carry-over from Objective-C.

   On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

       I guess for me it comes down to this:

       *Why were some and none chosen for as the cases for Optional?*

       As an extension of that, why does nil then represent none
       instead of the obvious none?

       There has to be a reason why it's not:

       enum Optional<T> {
       case some(T)
       case nil
       }

       None seems a lot more expressive and consistent with Optional.

       I am comfortable and use to nil, but with swift being a new
       language, I thought it was worth opening up a discussion about
       possibly changing direction a little here.

       Thanks,
       Brandon

       On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com> >>>>> <mailto:jordan_rose@apple.com <mailto:jordan_rose@apple.com>>> wrote:

       There are NilLiteralConvertible types other than Optional, but
       they’re dwindling now that pointer nullability is represented
       by Optional. That said, I’m not convinced renaming “nil” is
       worth it at this point. Similarity with other languages is
       still a good thing.

       It’s true that we might not have picked nil if it hadn’t been
       for Objective-C, but that doesn’t make it an invalid choice.
       There are lots of things in Swift we might have done
       differently if it weren’t for Objective-C and Cocoa.

       Jordan

       On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:

       Quick thought:

       If optional has a .none case, wouldn't it be more consistent
       to rename nil to none?

       Also, would nil make it into Swift if not for other languages?

       It also might make it somewhat clearer:

       var someInt: Int? = none //looks less like a pointer and more
       like a value of nothing

       1. It is more consistent with the optional enum
       2. The intent is arguably clearer
       3. nil makes it seem like it's a pointer
       4. Would nil be included if not for prior languages? Would
       "none" have been chosen as the keyword if nil wasn't prior art?

       One disadvantage is how close it is to .none, but with how
       common nil/none is used, some syntactic sugar might make it
       look nicer than always having the stray .

       On vacation from Orlando, poolside, with a quick thought,
       Brandon
       _______________________________________________
       swift-evolution mailing list
       swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
       https://lists.swift.org/mailman/listinfo/swift-evolution

   --
   -Saagar Jha

   _______________________________________________
   swift-evolution mailing list
   swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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> <mailto: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> <mailto: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

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


(Brandon Knope) #14

I know I know.

I should have framed this as removing NilLiteralConvertible from Optional and supplying it with a new keyword.

I don’t find nil to adequately represent what it is doing with optionals. It *looks* like it is setting a object to nil when this really isn’t the case. The optional is still very valid with a value of .none.

nil in swift is pretty different from nil in other languages. nil is mostly unsafe to access in other languages where in swift it is just a value representing no contained value.

nil in swift: safe to access. In other languages? Not so much (at least C / C++)

Brandon

···

On Jun 8, 2016, at 11:51 AM, David Waite <david@alkaline-solutions.com> wrote:

i