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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution