Remove nil and NilLiteralConvertible

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none,
would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is
clearer. In case of a semantically nullable struct, NilLiteralConvertible
usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

- Anton

I know we're making a lot of source-compatibility breaks in Swift 3 and so these lines seem blurry, but I think the spelling of "nil" is quite solidly in the "that ship has sailed" category, along with "struct" and "func" and "var".

John.

···

On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

It's been pointed out before that Optional being an enum type is treated
like an implementation detail. Currently, it is possible to teach the
concept of Optional without introducing enum types or generics. How would
you do so after elimination of nil?

···

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none,
would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null
is clearer. In case of a semantically nullable struct,
NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

- Anton

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

If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!

l8r
Sean

···

On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

.none or a more appropriate keyword like “none” (imo)

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

.none or a more appropriate keyword like “none” (imo)

My point is that `.none` exposes the underlying enum. The premise here is
that the enum is an implementation detail. You'll notice that, currently,
significant sugar and magic is devoted to allowing you to work with
optionals without ever writing `.some` or `none`. For example, `if let x =
...` and friends allow you to avoid writing `if case .some(let x) = ...`,
while you can write `return x` instead of `return .some(x)`. This was,
IIUC, a deliberate choice to allow progressive disclosure of the language
to learners. Renaming `nil` to `none` is a different proposal from Anton is
proposing here.

···

On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <bknope@me.com> wrote:

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated
like an implementation detail. Currently, it is possible to teach the
concept of Optional without introducing enum types or generics. How would
you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> > wrote:

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration
type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none,
would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null
is clearer. In case of a semantically nullable struct,
NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

- Anton

_______________________________________________
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

Is it really an implementation detail? It is very leaky if it is one
because it is highly exposed to everyone.

Regardless of whether or not it is an implementation detail, nil does not
adequately describe the “none” case it is trying to represent in my opinion

So you're arguing for renaming as opposed to removal then.

···

On Wed, Jun 8, 2016 at 3:59 PM, Brandon Knope <bknope@me.com> wrote:

B

On Jun 8, 2016, at 4:56 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <bknope@me.com> wrote:

.none or a more appropriate keyword like “none” (imo)

My point is that `.none` exposes the underlying enum. The premise here is
that the enum is an implementation detail. You'll notice that, currently,
significant sugar and magic is devoted to allowing you to work with
optionals without ever writing `.some` or `none`. For example, `if let x =
...` and friends allow you to avoid writing `if case .some(let x) = ...`,
while you can write `return x` instead of `return .some(x)`. This was,
IIUC, a deliberate choice to allow progressive disclosure of the language
to learners. Renaming `nil` to `none` is a different proposal from Anton is
proposing here.

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated
like an implementation detail. Currently, it is possible to teach the
concept of Optional without introducing enum types or generics. How would
you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> >> wrote:

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration
type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for
.none, would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null
is clearer. In case of a semantically nullable struct,
NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

- Anton

_______________________________________________
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

If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I could get behind this because “none” wouldn’t even need to be a keyword at all in that case, but there are probably difficult ambiguities down that road.

l8r
Sean

···

On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope@me.com> wrote:

1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward
2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages

I understand how nil works in the context of other languages. But looking at Optional:
public enum Optional<Wrapped> : NilLiteralConvertible {

    /// The absence of a value.
    ///
    /// In code, the absence of a value is typically written using the `nil`
    /// literal rather than the explicit `.none` enumeration case.
    case none

    /// The presence of a value, stored as `Wrapped`.
    case some(Wrapped)
}

These are not pointers and they sure look like one when you assign nil to an optional

B

Why would nil be chosen to represent the none case in the absence of other languages?

On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com> wrote:

If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!

l8r
Sean

On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

.none or a more appropriate keyword like “none” (imo)

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

When isn’t it?

l8r
Sean

···

On Jun 8, 2016, at 4:22 PM, Brandon Knope <bknope@me.com> wrote:

Yes it is the same keyword, but is it the same behavior from other languages?

Brandon

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

I think we also need to consider newbies coming from other languages. “nil” being a holdover makes it easier to understand what it means, having a “.none”/“none” duality makes it both seem inconsistent as well as dredge up language implementation details-now you have to explain that Optionals are actually enums internally. Using nil doesn’t lead to this kind of scenario, and they already (mostly) know what it means from other languages.

On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I could get behind this because “none” wouldn’t even need to be a keyword at all in that case, but there are probably difficult ambiguities down that road.

l8r
Sean

> On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope@me.com> wrote:
>
> 1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward
> 2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages
>
> I understand how nil works in the context of other languages. But looking at Optional:
> public enum Optional<Wrapped> : NilLiteralConvertible {
>
> /// The absence of a value.
> ///
> /// In code, the absence of a value is typically written using the `nil`
> /// literal rather than the explicit `.none` enumeration case.
> case none
>
> /// The presence of a value, stored as `Wrapped`.
> case some(Wrapped)
> }
>
>
> These are not pointers and they sure look like one when you assign nil to an optional
>
> B
>
> Why would nil be chosen to represent the none case in the absence of other languages?
>
>
>> On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com> wrote:
>>
>> If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!
>>
>> l8r
>> Sean
>>
>>
>>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
>>>
>>> .none or a more appropriate keyword like “none” (imo)
>>>
>>> Brandon
>>>
>>>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
>>>>
>>>> It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?
>>>>
>>>>
>>>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:
>>>> (No joking)
>>>> Points:
>>>>
>>>> 1. When nil was added to the language, we could not infer enumeration type:
>>>> if x != Optional.none { ... }
>>>>
>>>> Now it looks like this:
>>>> if x != .none { ... }
>>>>
>>>> If at this point we had a proposal to add nil as a replacement for .none, would we accept it?
>>>>
>>>> 2. nil is very generic, it only approximately allows to express the intentions.
>>>> In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.
>>>>
>>>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>>>
>>>> 4. There should be a single consistent terminology: no value in Swift equals none.
>>>>
>>>> - Anton
>>>>
>>>> _______________________________________________
>>>> 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
--
-Saagar Jha

I think you know I am very +1 on this :)

Brandon

···

On Jun 8, 2016, at 4:41 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

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

.none or a more appropriate keyword like “none” (imo)

Brandon

···

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

Is it really an implementation detail? It is very leaky if it is one because it is highly exposed to everyone.

Regardless of whether or not it is an implementation detail, nil does not adequately describe the “none” case it is trying to represent in my opinion

B

···

On Jun 8, 2016, at 4:56 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <bknope@me.com <mailto:bknope@me.com>> wrote:
.none or a more appropriate keyword like “none” (imo)

My point is that `.none` exposes the underlying enum. The premise here is that the enum is an implementation detail. You'll notice that, currently, significant sugar and magic is devoted to allowing you to work with optionals without ever writing `.some` or `none`. For example, `if let x = ...` and friends allow you to avoid writing `if case .some(let x) = ...`, while you can write `return x` instead of `return .some(x)`. This was, IIUC, a deliberate choice to allow progressive disclosure of the language to learners. Renaming `nil` to `none` is a different proposal from Anton is proposing here.

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

So are you proposing to disallow the following:

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = nil

Replacing it with the following:

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings.removeValueForKey("s2")

Thus subscript(_) could only be used for adding or updating, but not
removing, key/value pairs. I'm not sure how I feel about that yet.

Would you allow this?

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = .none

If so, that would make this example strange:

enum Stuff {
  case Bone, Dome, Chrome
}

let myStuff: [String:Stuff] = ["s1": .Bone, "s2": .Dome]
myStuff["s2"] = .none
myStuff["s1"] = .Chrome

In this last example, to me it seems less clear that a dictionary index is
dropped than if nil was used.

···

On Wed, Jun 08 2016 at 04:41:15 PM, Антон Жилин via swift-evolution <swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org> wrote:

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration
type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .
none, would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null
is clearer. In case of a semantically nullable struct,
NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

- Anton

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

1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward
2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages

I understand how nil works in the context of other languages. But looking at Optional:
public enum Optional<Wrapped> : NilLiteralConvertible {

    /// The absence of a value.
    ///
    /// In code, the absence of a value is typically written using the `nil`
    /// literal rather than the explicit `.none` enumeration case.
    case none

    /// The presence of a value, stored as `Wrapped`.
    case some(Wrapped)
}

These are not pointers and they sure look like one when you assign nil to an optional

B

Why would nil be chosen to represent the none case in the absence of other languages?

···

On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com> wrote:

If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!

l8r
Sean

On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

.none or a more appropriate keyword like “none” (imo)

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

In my other thread where this came up, my support is:
1. Removing NilLiteralConvertible conformance from Optional (apparently other people use this protocol?)
2. Introducing a new keyword that is sugar for .none

Would I like to remove nil and NilLiteralConvertible? Perhaps, but it seems that some people use them for other things and I would hate to take it away from them.

My concerns come down to this:
- It looks like a pointer
- People learning Swift as their first language will go to other languages and expect “nil” to be safe. Swift seems to be mostly alone here: nil is safe whereas in most languages it is not safe to dereference a nil pointer
- It is not consistent with the Optional enum naming
- It is not as descriptive or expressive

Brandon

···

On Jun 8, 2016, at 4:59 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Is it really an implementation detail? It is very leaky if it is one because it is highly exposed to everyone.

Regardless of whether or not it is an implementation detail, nil does not adequately describe the “none” case it is trying to represent in my opinion

B

On Jun 8, 2016, at 4:56 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <bknope@me.com <mailto:bknope@me.com>> wrote:
.none or a more appropriate keyword like “none” (imo)

My point is that `.none` exposes the underlying enum. The premise here is that the enum is an implementation detail. You'll notice that, currently, significant sugar and magic is devoted to allowing you to work with optionals without ever writing `.some` or `none`. For example, `if let x = ...` and friends allow you to avoid writing `if case .some(let x) = ...`, while you can write `return x` instead of `return .some(x)`. This was, IIUC, a deliberate choice to allow progressive disclosure of the language to learners. Renaming `nil` to `none` is a different proposal from Anton is proposing here.

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

Isn’t the only thing keeping nil relevant is the NilLiteralConvertible protocol?

Brandon

···

On Jun 8, 2016, at 5:08 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

I know we're making a lot of source-compatibility breaks in Swift 3 and so these lines seem blurry, but I think the spelling of "nil" is quite solidly in the "that ship has sailed" category, along with "struct" and "func" and "var".

John.

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

So are you proposing to disallow the following:

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = nil

Replacing it with the following:

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings.removeValueForKey("s2")

Thus subscript(_) could only be used for adding or updating, but not
removing, key/value pairs. I'm not sure how I feel about that yet.

Would you allow this?

let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = .none

If so, that would make this example strange:

enum Stuff {
case Bone, Dome, Chrome
}

let myStuff: [String:Stuff] = ["s1": .Bone, "s2": .Dome]
myStuff["s2"] = .none
myStuff["s1"] = .Chrome

In this last example, to me it seems less clear that a dictionary index is
dropped than if nil was used.

Why do you think that is? Why does nil express something different to you than Optional.none?

My guess is that you are thinking about it as an object being set to nil and thus being deleted when there is no strong reference to it.

Under the hood it may work this way, but I don’t think Optional is trying to present it this way

Brandon

···

On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 08 2016 at 04:41:15 PM, Антон Жилин via swift-evolution <swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org> wrote:

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration
type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .
none, would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null
is clearer. In case of a semantically nullable struct,
NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

- Anton

_______________________________________________
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

I was thinking about this too…but I’m not sure how feasible it would be.

However, I don’t find this any more confusing than having two ways to refer to it currently: nil and .none

none == sugar
.none == the underlying implementation of optional as Xiaodi put it (I am starting to see this view)

Brandon

···

On Jun 8, 2016, at 5:13 PM, Sean Heber <sean@fifthace.com> wrote:

If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I could get behind this because “none” wouldn’t even need to be a keyword at all in that case, but there are probably difficult ambiguities down that road.

l8r
Sean

On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope@me.com> wrote:

1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward
2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages

I understand how nil works in the context of other languages. But looking at Optional:
public enum Optional<Wrapped> : NilLiteralConvertible {

   /// The absence of a value.
   ///
   /// In code, the absence of a value is typically written using the `nil`
   /// literal rather than the explicit `.none` enumeration case.
   case none

   /// The presence of a value, stored as `Wrapped`.
   case some(Wrapped)
}

These are not pointers and they sure look like one when you assign nil to an optional

B

Why would nil be chosen to represent the none case in the absence of other languages?

On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com> wrote:

If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!

l8r
Sean

On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

.none or a more appropriate keyword like “none” (imo)

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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

Yes it is the same keyword, but is it the same behavior from other languages?

Brandon

···

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

I think we also need to consider newbies coming from other languages. “nil” being a holdover makes it easier to understand what it means, having a “.none”/“none” duality makes it both seem inconsistent as well as dredge up language implementation details-now you have to explain that Optionals are actually enums internally. Using nil doesn’t lead to this kind of scenario, and they already (mostly) know what it means from other languages.

On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I could get behind this because “none” wouldn’t even need to be a keyword at all in that case, but there are probably difficult ambiguities down that road.

l8r
Sean

> On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope@me.com <mailto:bknope@me.com>> wrote:
>
> 1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward
> 2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages
>
> I understand how nil works in the context of other languages. But looking at Optional:
> public enum Optional<Wrapped> : NilLiteralConvertible {
>
> /// The absence of a value.
> ///
> /// In code, the absence of a value is typically written using the `nil`
> /// literal rather than the explicit `.none` enumeration case.
> case none
>
> /// The presence of a value, stored as `Wrapped`.
> case some(Wrapped)
> }
>
>
> These are not pointers and they sure look like one when you assign nil to an optional
>
> B
>
> Why would nil be chosen to represent the none case in the absence of other languages?
>
>
>> On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:
>>
>> If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!
>>
>> l8r
>> Sean
>>
>>
>>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> .none or a more appropriate keyword like “none” (imo)
>>>
>>> Brandon
>>>
>>>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?
>>>>
>>>>
>>>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> (No joking)
>>>> Points:
>>>>
>>>> 1. When nil was added to the language, we could not infer enumeration type:
>>>> if x != Optional.none { ... }
>>>>
>>>> Now it looks like this:
>>>> if x != .none { ... }
>>>>
>>>> If at this point we had a proposal to add nil as a replacement for .none, would we accept it?
>>>>
>>>> 2. nil is very generic, it only approximately allows to express the intentions.
>>>> In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.
>>>>
>>>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>>>
>>>> 4. There should be a single consistent terminology: no value in Swift equals none.
>>>>
>>>> - Anton
>>>>
>>>> _______________________________________________
>>>> 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha

Here I have a contrived example (I am bad at trying to explain my point -_-):

When I see nil, I think of reference types. I.e. Objective-C:

NSMutableString *mutableString = [[NSMutableString alloc] initWithString:@"123"];
__weak NSMutableString *reference = mutableString;
    
reference = mutableString;
    
[reference appendString:@"456"];
mutableString = nil;

//memory is now deallocated because strong references are eliminated
// BUT reference is now nil! This is expected with reference types

In Objective-C we have to use nil to manage when objects are deallocated. We also have to use __weak to avoid retain cycles etc...

This behavior is consistent with other languages with reference semantics.

However, in Swift, optionals are value types as we all know (though they can wrap reference types):

var number1: Int? = nil
var number2: Int? = number1

number1 == number2

number1 = 3
number2 == number1 // FALSE. This behavior is obviously different from Objective-C and we expect that knowing that it’s a value type

On first look, it looks like reference semantics because you see nil and remember it from other languages. OR you learn this behavior in Swift and expect it to work the same in other languages. Either way the behavior isn’t exactly consistent between all languages. Even nil in Objective-C is different than most languages because you are allowed to send messages to it.

As far as I know, setting:
number1 = nil

does not deallocate number1. It is still an optional with enough space to wrap an Int that happens to just be set to .none currently.

It looks like you are deallocating something if that is the behavior you expect from other languages upon seeing nil.

nil can have similar behaviors in both languages, but they can also have very dissimilar behaviors too.

My main point comes down to: nil makes it look like a pointer and thus makes you see it as a reference type at first glance until you completely retrain yourself. This is not how nil works with values in Swift and I think some might find that surprising down the road when:
A) They learn Swift first and move to another language and see a different behavior than they are use to
B) They come from another language and associate seeing nil with the type being a reference and being surprised

or C…you just have to remember the differences.

I probably made my point even worse but I can only try!
Brandon

···

On Jun 8, 2016, at 5:37 PM, Sean Heber <sean@fifthace.com> wrote:

When isn’t it?

l8r
Sean

On Jun 8, 2016, at 4:22 PM, Brandon Knope <bknope@me.com> wrote:

Yes it is the same keyword, but is it the same behavior from other languages?

Brandon

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

I think we also need to consider newbies coming from other languages. “nil” being a holdover makes it easier to understand what it means, having a “.none”/“none” duality makes it both seem inconsistent as well as dredge up language implementation details-now you have to explain that Optionals are actually enums internally. Using nil doesn’t lead to this kind of scenario, and they already (mostly) know what it means from other languages.

On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I could get behind this because “none” wouldn’t even need to be a keyword at all in that case, but there are probably difficult ambiguities down that road.

l8r
Sean

On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope@me.com> wrote:

1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward
2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages

I understand how nil works in the context of other languages. But looking at Optional:
public enum Optional<Wrapped> : NilLiteralConvertible {

   /// The absence of a value.
   ///
   /// In code, the absence of a value is typically written using the `nil`
   /// literal rather than the explicit `.none` enumeration case.
   case none

   /// The presence of a value, stored as `Wrapped`.
   case some(Wrapped)
}

These are not pointers and they sure look like one when you assign nil to an optional

B

Why would nil be chosen to represent the none case in the absence of other languages?

On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com> wrote:

If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!

l8r
Sean

On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

.none or a more appropriate keyword like “none” (imo)

Brandon

On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?

On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <swift-evolution@swift.org> wrote:
(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none, would we accept it?

2. nil is very generic, it only approximately allows to express the intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift equals none.

- Anton

_______________________________________________
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
--
-Saagar Jha

I think we also need to consider newbies coming from other languages. “nil”
being a holdover makes it easier to understand what it means, having a
“.none”/“none” duality makes it both seem inconsistent as well as dredge up
language implementation details-now you have to explain that Optionals are
actually enums internally. Using nil doesn’t lead to this kind of scenario,
and they already (mostly) know what it means from other languages.

···

On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution < swift-evolution@swift.org> wrote:

If there’s both “.none” and “none”, then I think that’d be more confusing
*because of* the naming consistency, IMO. I’d look at that as a newbie and
wonder why in the world this word sometimes has a dot and sometimes doesn’t.

If enum cases could be referred to without the leading “.” then perhaps I
could get behind this because “none” wouldn’t even need to be a keyword at
all in that case, but there are probably difficult ambiguities down that
road.

l8r
Sean

> On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope@me.com> wrote:
>
> 1. People will find .none ugly which is why I think it could be replaced
by a none keyword. It is awkward
> 2. none is more descriptive than nil in this case. The case is named
none (consistency!) and nil is a holdover from other languages
>
> I understand how nil works in the context of other languages. But
looking at Optional:
> public enum Optional<Wrapped> : NilLiteralConvertible {
>
> /// The absence of a value.
> ///
> /// In code, the absence of a value is typically written using the
`nil`
> /// literal rather than the explicit `.none` enumeration case.
> case none
>
> /// The presence of a value, stored as `Wrapped`.
> case some(Wrapped)
> }
>
>
> These are not pointers and they sure look like one when you assign nil
to an optional
>
> B
>
> Why would nil be chosen to represent the none case in the absence of
other languages?
>
>
>> On Jun 8, 2016, at 4:55 PM, Sean Heber <sean@fifthace.com> wrote:
>>
>> If you add a new keyword called “none” without the period, but keep
allowing “.none” to work because Optional is really an enum… then I don’t
really see what has been gained here at all - you’re basically back to
nil/.none => 2 ways to say the same thing!
>>
>> l8r
>> Sean
>>
>>
>>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>> .none or a more appropriate keyword like “none” (imo)
>>>
>>> Brandon
>>>
>>>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>>>>
>>>> It's been pointed out before that Optional being an enum type is
treated like an implementation detail. Currently, it is possible to teach
the concept of Optional without introducing enum types or generics. How
would you do so after elimination of nil?
>>>>
>>>>
>>>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин < > swift-evolution@swift.org> wrote:
>>>> (No joking)
>>>> Points:
>>>>
>>>> 1. When nil was added to the language, we could not infer enumeration
type:
>>>> if x != Optional.none { ... }
>>>>
>>>> Now it looks like this:
>>>> if x != .none { ... }
>>>>
>>>> If at this point we had a proposal to add nil as a replacement for
.none, would we accept it?
>>>>
>>>> 2. nil is very generic, it only approximately allows to express the
intentions.
>>>> In case of Optional, .none is clearer. In case of JSON processing,
.null is clearer. In case of a semantically nullable struct,
NilLiteralConvertible usually goes to default constructor.
>>>>
>>>> 3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.
>>>>
>>>> 4. There should be a single consistent terminology: no value in Swift
equals none.
>>>>
>>>> - Anton
>>>>
>>>> _______________________________________________
>>>> 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

--
-Saagar Jha