Discussion: Why is "nil" not "none"


(Anton Zhilin) #1

The difference between nil and .none is that the former is more
"generic" than the latter.

NilLiteralConvertible protocol expresses types that can contain "null" as
legal values. `nil` does not have a type, it's just a token that is casted
to whatever NilLiteralConvertible type is expected. It is used in JSON
libraries, for example:

let tree: JSON = ["name": "Alex", "age": 20, "email": nil]

Here, nil would be inferred to have our custom JSON type.
The same example with none would look a bit more weird:

let tree: JSON = ["name": "Alex", "age": 20, "email": none]

None of what type? Of String? Of Int? Of JSON? There are no optionals in
this code. And a "null" present in JSON is different than no JSON in Swift.

Optional is the most significant example of NilLiteralConvertible, but
there are other users that would suffer from renaming. We could remove
NilLiteralConvertible at all, but look at the example in this case:

let tree: JSON = ["name": "Alex", "age": 20, "email": JSON.nullValue]

That would hurt immersion of the DSL.

I think some Core team member told that they intentionally keep two ways of
handling Optional: one using nil, and the other treating it like other
enums.

- Anton


(Brandon Knope) #2

The difference between nil and .none is that the former is more "generic" than the latter.

NilLiteralConvertible protocol expresses types that can contain "null" as legal values. `nil` does not have a type, it's just a token that is casted to whatever NilLiteralConvertible type is expected. It is used in JSON libraries, for example:

let tree: JSON = ["name": "Alex", "age": 20, "email": nil]

Here, nil would be inferred to have our custom JSON type.
The same example with none would look a bit more weird:

let tree: JSON = ["name": "Alex", "age": 20, "email": none]

None of what type? Of String? Of Int? Of JSON? There are no optionals in this code. And a "null" present in JSON is different than no JSON in Swift.

I have seen an example like this several times. In every case, I find the “none” one to be clearer. Why? Because it indicates that there is no email. nil to me looks like it could be a null pointer that could have bad consequences when accessed

nil is special word that we are use to from other languages. It *sounds* natural in this case because it is familiar.

I am not familiar with JSON libraries, but I don’t think that should guide the direction on which way to go.

Also, I am more specifically referring to nil with the use of optionals, not NilLiteralConvertible:

let i: Int? = nil
let i: Int? = .none

There are two ways to write the same thing with one being far clearer in my opinion. What does nil mean in this case? It precisely represents Optional<Int>.none making it somewhat redundant and surprising considering how nil is used in other languages.

More specifically, what is nil? 0? A pointer? A representation of nothing (again implying none!)?

I am very curious how new programmers coming to Swift as their first language would react to using nil in other languages. I think they would be very surprised.

Optional is the most significant example of NilLiteralConvertible, but there are other users that would suffer from renaming. We could remove NilLiteralConvertible at all, but look at the example in this case:

let tree: JSON = ["name": "Alex", "age": 20, "email": JSON.nullValue]

This is somewhat more explicit and clearer in my opinion. Again, I am not familiar with JSON libraries so this could be why it looks clearer to me.

From your response, I see the words “nil”, “null”, and “none”. Doesn’t this seem a little excessive and maybe confusing for people?

Thanks,
Brandon

···

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

That would hurt immersion of the DSL.

I think some Core team member told that they intentionally keep two ways of handling Optional: one using nil, and the other treating it like other enums.

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


(Anton Zhilin) #3

I think you should explore the direction of removing NilLiteralConvertible
entirely, together with nil. My example could instead use:

let tree: JSON = ["name": "Alex", "age": 20, "email": .null]

Rationale would be that when nil was added to the language, enum
constructors could not omit their types. Now there is no reason for nil,
especially that it makes developers use only approximately suitable terms.

- Anton

···

2016-06-08 19:12 GMT+03:00 Brandon Knope <bknope@me.com>:

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

The difference between nil and .none is that the former is more
"generic" than the latter.

NilLiteralConvertible protocol expresses types that can contain "null" as
legal values. `nil` does not have a type, it's just a token that is casted
to whatever NilLiteralConvertible type is expected. It is used in JSON
libraries, for example:

let tree: JSON = ["name": "Alex", "age": 20, "email": nil]

Here, nil would be inferred to have our custom JSON type.
The same example with none would look a bit more weird:

let tree: JSON = ["name": "Alex", "age": 20, "email": none]

None of what type? Of String? Of Int? Of JSON? There are no optionals in
this code. And a "null" present in JSON is different than no JSON in Swift.

I have seen an example like this several times. In every case, I find the
“none” one to be clearer. Why? Because it indicates that there is no email.
nil to me looks like it could be a null pointer that could have bad
consequences when accessed

nil is special word that we are use to from other languages. It *sounds*
natural in this case because it is familiar.

I am not familiar with JSON libraries, but I don’t think that should guide
the direction on which way to go.

Also,* I am more specifically referring to nil with the use of optionals,
not NilLiteralConvertible:*

let i: Int? = nil
let i: Int? = .none

There are two ways to write the same thing with one being far clearer in
my opinion. What does nil mean in this case? It precisely represents
Optional<Int>.none making it somewhat redundant and surprising considering
how nil is used in other languages.

More specifically, what is nil? 0? A pointer? A representation of nothing
(again implying none!)?

I am very curious how new programmers coming to Swift as their first
language would react to using nil in other languages. I think they would be
very surprised.

Optional is the most significant example of NilLiteralConvertible, but
there are other users that would suffer from renaming. We could remove
NilLiteralConvertible at all, but look at the example in this case:

let tree: JSON = ["name": "Alex", "age": 20, "email": JSON.nullValue]

This is somewhat more explicit and clearer in my opinion. Again, I am not
familiar with JSON libraries so this could be why it looks clearer to me.

From your response, I see the words “nil”, “null”, and “none”. Doesn’t
this seem a little excessive and maybe confusing for people?

Thanks,
Brandon

That would hurt immersion of the DSL.

I think some Core team member told that they intentionally keep two ways
of handling Optional: one using nil, and the other treating it like other
enums.

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