[swift-evolution] Discussion: Why is "nil" not "none"
Vladimir.S
svabox at gmail.com
Wed Jun 8 09:56:13 CDT 2016
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>> 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>> 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>> 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>> 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>> 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>> 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>> 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>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> 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>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> 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 <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
>
More information about the swift-evolution
mailing list