[swift-evolution] Remove nil and NilLiteralConvertible

[Xiaodi Wu]

On Wed, Jun 8, 2016 at 3:59 PM, Brandon Knope <bknope at me.com> wrote:

> Is it really an implementation detail? It is very leaky if it is one
> because it is highly exposed to everyone.
>
> Regardless of whether or not it is an implementation detail, nil does not
> adequately describe the “none” case it is trying to represent in my opinion
>

So you're arguing for renaming as opposed to removal then.


>
>
> B
>
>
> On Jun 8, 2016, at 4:56 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <bknope at me.com> wrote:
>
>> .none or a more appropriate keyword like “none” (imo)
>>
>>
> My point is that `.none` exposes the underlying enum. The premise here is
> that the enum is an implementation detail. You'll notice that, currently,
> significant sugar and magic is devoted to allowing you to work with
> optionals without ever writing `.some` or `none`. For example, `if let x =
> ...` and friends allow you to avoid writing `if case .some(let x) = ...`,
> while you can write `return x` instead of `return .some(x)`. This was,
> IIUC, a deliberate choice to allow progressive disclosure of the language
> to learners. Renaming `nil` to `none` is a different proposal from Anton is
> proposing here.
>
>
>> Brandon
>>
>> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> It's been pointed out before that Optional being an enum type is treated
>> like an implementation detail. Currently, it is possible to teach the
>> concept of Optional without introducing enum types or generics. How would
>> you do so after elimination of nil?
>>
>>
>> On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <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
>>>
>>>
>> _______________________________________________
>> 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/20160608/83bf7aef/attachment.html>