[swift-evolution] Remove nil and NilLiteralConvertible

[Saagar Jha]

I think we also need to consider newbies coming from other languages. “nil”
being a holdover makes it easier to understand what it means, having a
“.none”/“none” duality makes it both seem inconsistent as well as dredge up
language implementation details-now you have to explain that Optionals are
actually enums internally. Using nil doesn’t lead to this kind of scenario,
and they already (mostly) know what it means from other languages.

On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution <
swift-evolution at swift.org> wrote:

> If there’s both “.none” and “none”, then I think that’d be more confusing
> *because of* the naming consistency, IMO. I’d look at that as a newbie and
> wonder why in the world this word sometimes has a dot and sometimes doesn’t.
>
> If enum cases could be referred to without the leading “.” then perhaps I
> could get behind this because “none” wouldn’t even need to be a keyword at
> all in that case, but there are probably difficult ambiguities down that
> road.
>
> l8r
> Sean
>
>
> > On Jun 8, 2016, at 4:04 PM, Brandon Knope <bknope at me.com> wrote:
> >
> > 1. People will find .none ugly which is why I think it could be replaced
> by a none keyword. It is awkward
> > 2. none is more descriptive than nil in this case. The case is named
> none (consistency!) and nil is a holdover from other languages
> >
> > I understand how nil works in the context of other languages. But
> looking at Optional:
> > public enum Optional<Wrapped> : NilLiteralConvertible {
> >
> >     /// The absence of a value.
> >     ///
> >     /// In code, the absence of a value is typically written using the
> `nil`
> >     /// literal rather than the explicit `.none` enumeration case.
> >     case none
> >
> >     /// The presence of a value, stored as `Wrapped`.
> >     case some(Wrapped)
> > }
> >
> >
> > These are not pointers and they sure look like one when you assign nil
> to an optional
> >
> > B
> >
> > Why would nil be chosen to represent the none case in the absence of
> other languages?
> >
> >
> >> On Jun 8, 2016, at 4:55 PM, Sean Heber <sean at fifthace.com> wrote:
> >>
> >> If you add a new keyword called “none” without the period, but keep
> allowing “.none” to work because Optional is really an enum… then I don’t
> really see what has been gained here at all - you’re basically back to
> nil/.none => 2 ways to say the same thing!
> >>
> >> l8r
> >> Sean
> >>
> >>
> >>> On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> .none or a more appropriate keyword like “none” (imo)
> >>>
> >>> 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
> >>>
> >>> _______________________________________________
> >>> 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
>
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/5ed677ad/attachment.html>