[swift-evolution] Remove nil and NilLiteralConvertible

[Roth Michaels]

On Wed, Jun 08 2016 at 05:16:26 PM, Brandon Knope <bknope at me.com> wrote:
>> On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution <swift-evolution at swift.org> wrote:
>> 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?

While I do think `nil` expresses something slightly different than
`Optional.none`, that is not why I think this example is unclear.  When
assigning and clearing multilpe enum values in a dictionary on consecutive lines
`.none` is less visually distinct from `nil`[1] and takes a little more
care to recognize that `.none` is `Optional.none` and not `Stuff.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.

Nope, I'm not thinking about references.  I do think there is a slight
conceptual difference between literal `nil` and `Optional.none`: the
former is a literal representation of nothing, and the later a value
that acts as a placeholder for nothing.

Disallowing `nil` in favor of `.none` would only make sense to me if you
also removed the ability to assign other literals or other values
without wrapping the value with .some(_) (I'm not sure if you'd have to
write Optional<T>.some(_) to get type inference working correctly.
Removing `nil` would only make sense to me if things in Swift were more
like Scala regarding Option type assignment;

this:

var myInt: Int?
myInt = 3
myInt = nil

becomes this:

var myInt: Int?
myInt = .some(3)
myInt = .none

Personally, not needing to perform this sort of wrapping is something I
prefer about writing Swift vs Scala.

It has been discussed that `nil` might confuse users to thinking it was
the same `nil` as in other languages (e.g. 0 in Objective-C).  While
maybe a less common form of confusion, the same could be said for `.none`
where in Swift `.none` can't be stored in a Dictionary but it can be in
Scala.

Also, the fact that nil is used for any kind of nothingness not just
Optional.none (nil unsafe pointers, etc.) it makes sense to me that
nil is used for all assignments to types that can be nothing (just
because it is implemented with an enum, I don't see why that makes
Optional.none special vs other things that are currently nil convertible).

-- 
Roth

[1]: I don't think syntax highlighting alone should be a solution.