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 > <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 <[email protected]> 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 >>>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> -- >> -Saagar Jha > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
