[swift-evolution] Remove nil and NilLiteralConvertible

[Roth Michaels]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution