[swift-evolution] Discussion: Why is "nil" not "none"

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


This is precisely the point I was trying to make.

“nil” is a holdover from other languages; i.e. we are comfortable with using it. I think there are better alternatives to consider.

However, when evaluating whether it makes sense with swift, I think it fails some of the criteria for inclusion.

My biggest bet why people are against .none is that the . looks noisy and unclean. This is why I am suggesting “none” as sugar for .none even though it might seem quite silly.

I also bet that 9 times out of 10, when people see nil they think of pointers and not optionals. Maybe this will take time to retrain ourselves to think optionality, but now nil is used for different things in different languages

Brandon

> On Jun 8, 2016, at 10:56 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Reading the thread.. I wonder if we need "nil" at all, why not use (just a question, not a suggestion) .none ? I.e. now we can use nil and .none in the same situations, .none is just 2 symbols longer, '.none' highlight that Optional is a special type (that there is .some(T) in Optional), no confusion if it is related to pointers etc.
> 
> var i : Int? = 10
> if i != .none { print(i) }
> i = .none
> print(i)
> 
> var i : Int? = 10
> if i != nil { print(i) }
> i = nil
> print(i)
> 
> i.e. the same thing expressed in 2 different but similar ways. Probably I'm missing something.
> 
> On 08.06.2016 12:33, J. Charles M. N. via swift-evolution wrote:
>> I'am not either for removing nil nor renaming it none, I think that they
>> are conceptually different things.
>> 
>> This syntactic sugar brings unfortunately many things around. One
>> fastidious thing is it multiple semantics: As null pointer. As none value.
>> I am personally not favorable for multiples semantics keywords.
>> 
>> Aside, if it come up to revisiting nil concept we should bring the other
>> chimera (unit, Void, bottom type etc).
>> 
>> --
>> J. Charles
>> 
>> Le 8 juin 2016 à 04:18, Muse M via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> a écrit :
>> 
>>> None would be similar to Null or nothing about the types in that sense
>>> which None is not a type.
>>> Nil would be interpret as Int, Float, String, etc
>>> 
>>> 
>>> 
>>> On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>> 
>>>    No clue as to the origins, but if you insist on using none. you can do:
>>> 
>>>    let a : Int? = .none
>>>    let b : Int? = .some(5)
>>> 
>>>    Using the simpler
>>> 
>>>    let a : Int? = nil
>>>    let b : Int? = 5
>>> 
>>>    is just sugar.
>>>    Maybe it was foresight to prevent people from saying, if I can do:
>>> 
>>>    let a : Int? = none
>>> 
>>>    Why can't I do:
>>> 
>>>    let b : Int? = some(5)
>>> 
>>>    And then go a step further by asking for all enum to be access
>>>    without the leading dot; scary thought.
>>> 
>>>    So it may be better to stick with '.none' and sugared 'nil'.
>>> 
>>>    Dany
>>> 
>>>    Le 7 juin 2016 à 20:16, Brandon Knope via swift-evolution
>>>    <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> a écrit :
>>> 
>>>>    That's exactly the point I was going for.
>>>> 
>>>>    none makes more sense in this context than nil in my opinion
>>>> 
>>>>    Brandon
>>>> 
>>>>    On Jun 7, 2016, at 8:10 PM, Saagar Jha <saagarjha28 at gmail.com <mailto:saagarjha28 at gmail.com>
>>>>    <mailto:saagarjha28 at gmail.com <mailto:saagarjha28 at gmail.com>>> wrote:
>>>> 
>>>>>    Well, some is the opposite of none in that if I don’t have some, I
>>>>>    have none. nil is just a carry-over from Objective-C.
>>>>> 
>>>>>    On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution
>>>>>    <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>>>> 
>>>>>        I guess for me it comes down to this:
>>>>> 
>>>>>        *Why were some and none chosen for as the cases for Optional?*
>>>>> 
>>>>>        As an extension of that, why does nil then represent none
>>>>>        instead of the obvious none?
>>>>> 
>>>>>        There has to be a reason why it's not:
>>>>> 
>>>>>        enum Optional<T> {
>>>>>        case some(T)
>>>>>        case nil
>>>>>        }
>>>>> 
>>>>>        None seems a lot more expressive and consistent with Optional.
>>>>> 
>>>>>        I am comfortable and use to nil, but with swift being a new
>>>>>        language, I thought it was worth opening up a discussion about
>>>>>        possibly changing direction a little here.
>>>>> 
>>>>>        Thanks,
>>>>>        Brandon
>>>>> 
>>>>>        On Jun 7, 2016, at 7:57 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>
>>>>>        <mailto:jordan_rose at apple.com <mailto:jordan_rose at apple.com>>> wrote:
>>>>> 
>>>>>>        There are NilLiteralConvertible types other than Optional, but
>>>>>>        they’re dwindling now that pointer nullability is represented
>>>>>>        by Optional. That said, I’m not convinced renaming “nil” is
>>>>>>        worth it at this point. Similarity with other languages is
>>>>>>        still a good thing.
>>>>>> 
>>>>>>        It’s true that we might not have picked nil if it hadn’t been
>>>>>>        for Objective-C, but that doesn’t make it an invalid choice.
>>>>>>        There are lots of things in Swift we might have done
>>>>>>        differently if it weren’t for Objective-C and Cocoa.
>>>>>> 
>>>>>>        Jordan
>>>>>> 
>>>>>> 
>>>>>>>        On Jun 5, 2016, at 12:35, Brandon Knope via swift-evolution
>>>>>>>        <swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>>        <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>>>>>> 
>>>>>>>        Quick thought:
>>>>>>> 
>>>>>>>        If optional has a .none case, wouldn't it be more consistent
>>>>>>>        to rename nil to none?
>>>>>>> 
>>>>>>>        Also, would nil make it into Swift if not for other languages?
>>>>>>> 
>>>>>>>        It also might make it somewhat clearer:
>>>>>>> 
>>>>>>>        var someInt: Int? = none //looks less like a pointer and more
>>>>>>>        like a value of nothing
>>>>>>> 
>>>>>>>        1. It is more consistent with the optional enum
>>>>>>>        2. The intent is arguably clearer
>>>>>>>        3. nil makes it seem like it's a pointer
>>>>>>>        4. Would nil be included if not for prior languages? Would
>>>>>>>        "none" have been chosen as the keyword if nil wasn't prior art?
>>>>>>> 
>>>>>>>        One disadvantage is how close it is to .none, but with how
>>>>>>>        common nil/none is used, some syntactic sugar might make it
>>>>>>>        look nicer than always having the stray .
>>>>>>> 
>>>>>>>        On vacation from Orlando, poolside, with a quick thought,
>>>>>>>        Brandon
>>>>>>>        _______________________________________________
>>>>>>>        swift-evolution mailing list
>>>>>>>        swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>>>        https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> 
>>>>>        _______________________________________________
>>>>>        swift-evolution mailing list
>>>>>        swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>        https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>>    --
>>>>>    -Saagar Jha
>>>>    _______________________________________________
>>>>    swift-evolution mailing list
>>>>    swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>    https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>>    _______________________________________________
>>>    swift-evolution mailing list
>>>    swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>    https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto: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
>> 
> _______________________________________________
> 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/36e277b0/attachment-0001.html>


More information about the swift-evolution mailing list