[swift-evolution] Remove nil and NilLiteralConvertible

[Pyry Jahkola]

I don't see a reason to rename or remove the `nil` literal.

But I can come up with a concrete reason to deprecate NilLiteralConvertible: The language has made Optional a very specific thing with `if let` syntax, implicit wrapping, and optional chaining to name a few. But the second most common way (I guess) to create an Optional—by using the `nil` literal—isn't actually guaranteed to create an Optional.

    let condition: Bool
    let x = condition ? 1 : nil
    // error: result values in '? :' expression have mismatching types 'Int' and '_'

An expression like the above doesn't compile because the compiler can't tell what type `nil` should initialise. (Currently, at least Optional<Int> and ImplicitlyUnwrappedOptional<Int> seem possible, but with NilLiteralConvertible, something like a conforming MyJSON could be as well!) This, I think, can be confusing to new users. And life would be simpler if `nil` always stood for `Optional.none`, which would then infer the associated Wrapped type respectfully.

So no, I don't support this idea but I think we should sunset NilLiteralConvertible.

— Pyry

PS. Besides, the above statement will compile with any of the following edits:

    let x = condition ? 1 : Optional.none
    let x = condition ? 1 : nil as Optional
    let x = condition ? 1 : Optional()
    let x = condition ? 1 as Optional : nil
    let x = condition ? 1 as Int? : nil
    let x = condition ? Optional(1) : nil
    let x: Int? = condition ? 1 : nil

> On 08 Jun 2016, at 23:41, Антон Жилин via swift-evolution <swift-evolution at swift.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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/32652cb4/attachment.html>