[swift-evolution] Remove nil and NilLiteralConvertible

Brandon Knope bknope at me.com
Wed Jun 8 16:16:26 CDT 2016





> On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> 
> 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 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
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution





More information about the swift-evolution mailing list