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