[swift-evolution] [Pitch] Nil struct

[Karl]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161109/44f8fbf0/attachment.html>