nil is not only usable with Optionals, although that is its most common usage.
Any type implementing NilLiteralConvertible can be initialized with a nil literal -DW > On Jun 8, 2016, at 10:45 AM, Brandon Knope via swift-evolution > <swift-evolution@swift.org> wrote: > > 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@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 <saagarjh...@gmail.com >>>>> <mailto:saagarjh...@gmail.com> >>>>> <mailto:saagarjh...@gmail.com <mailto:saagarjh...@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@swift.org <mailto:swift-evolution@swift.org> >>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@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_r...@apple.com >>>>>> <mailto:jordan_r...@apple.com> >>>>>> <mailto:jordan_r...@apple.com <mailto:jordan_r...@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@swift.org <mailto:swift-evolution@swift.org> >>>>>>>> <mailto:swift-evolution@swift.org >>>>>>>> <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
