-1 Personally, I don’t like writing “nil” at all. In my understanding of Swift, “nil” is simply a C-like shorthand for "Optional<T>.none”. If the compiler can’t infer T (such as “let a = nil”), it should fall-back to Optional<Any>.none; I’m very surprised that this isn’t the case currently.
There is a bug where the type-checker can’t always infer the type when you just write “.none”, but outside of that I think it’s a swiftier way of doing things: https://bugs.swift.org/browse/SR-2302 <https://bugs.swift.org/browse/SR-2302> I would be more likely to support the opposite proposal - to eliminate the “nil” literal altogether and replace it with “.none”. - Karl > On 8 Nov 2016, at 21:30, Anton Zhilin via swift-evolution > <swift-evolution@swift.org> wrote: > > Gist link <https://gist.github.com/Anton3/ba56a29986c59e9595368be3cb02fb1b> > Introduction > > Change nil literal type from () to Nil. > Before: > > public protocol ExpressibleByNilLiteral { > init(nilLiteral: ()) > } > After: > > public struct Nil { > init() > } > public protocol ExpressibleByNilLiteral { > associatedtype NilLiteralType = Nil > init(nilLiteral: NilLiteralType) > } > Motivation > > Currently, nil differs from other literals: it doesn’t have its own type. > But in some cases we want to deal directly with it, without creating any > instances. > > The most important use case is comparison of an Optional to nil. > Currently, this operation is implemented using a hidden struct > _OptionalNilComparisonType, > which is needed precisely because because nil does not have its own type. > Removal of such underscored types is one of the goals stated in Generics > manifesto. > > Additionally, declaration of ExpressibleByNilLiteral differs from all other > Expressibles, > because it doesn’t have a Literal type. It is generally beneficial to > eliminate special cases. > > Proposed solution > > Introduce a struct Nil, which becomes the default type for nil literals: > > public struct Nil : ExpressibleByNilLiteral { > init() > init(nilLiteral: NilLiteralType) > } > > let a = nil > print(type(of: a)) //=> Nil > Rewrite ExpressibleByNilLiteral: > > public protocol ExpressibleByNilLiteral { > associatedtype NilLiteralType = Nil > init(nilLiteral: NilLiteralType) > } > Make use of Nil in the standard library: > > public func == <T>(left: T?, right: Nil) > public func == <T>(left: Nil, right: T?) > public func != <T>(left: T?, right: Nil) > public func != <T>(left: Nil, right: T?) > public func ~= <T>(left: Nil, right: T?) > Source compatibility > > Nil identifier is taken, therefore applications that already use it will stop > compiling. > Automatic migration is somewhat possible by renaming of the old entity; > manual migration is recommended. > > Applications that use declare ExpressibleByNilLiteral conformances will stop > compiling. > Automatic migration is possible. > > Effect on ABI stability > > Applications that use Nil identifier will have to make ABI-breaking changes. > > Otherwise, the change can mostly be applied in an ABI-compatible manner. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution