[swift-evolution] Remove nil and NilLiteralConvertible
Charlie Monroe
charlie at charliemonroe.net
Thu Jun 9 01:06:30 CDT 2016
My objection to this is that .none is a fairly common member in various enums (besides Optional) and it's a mess already:
enum EventDataRenderType {
case none
case tab
case blockClosed
case blockOpened
}
let data = self.data
if data.customization?.renderType == .none {
/// Was it compared to Optional.none, or EventDataRenderType,
/// since data.customization?.renderType == .tab is completely
/// valid...
}
If `none` became a keyword as suggested by some, would it be allowed to have .none in other enums?
> On Jun 8, 2016, at 10:41 PM, Антон Жилин via swift-evolution <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
More information about the swift-evolution
mailing list