Re: [swift-evolution] [Pitch] Nil struct

> On 9 Nov 2016, at 16:55, Karl wrote: > > If the compiler can’t infer T (such as “let a = nil”), it should fall-back to > Optional.none; I’m very surprised that this isn’t the case currently. > Oh, it is the case currently: let a = nil error: repl.swift:1:9: error: 'nil' requires a contextu

Re: [swift-evolution] [Pitch] Nil struct

-1 Personally, I don’t like writing “nil” at all. In my understanding of Swift, “nil” is simply a C-like shorthand for "Optional.none”. If the compiler can’t infer T (such as “let a = nil”), it should fall-back to Optional.none; I’m very surprised that this isn’t the case currently. There is a

Re: [swift-evolution] [Pitch] Nil struct

> On Nov 8, 2016, at 1:05 PM, Anton Zhilin wrote: > > 2016-11-08 23:43 GMT+03:00 Jose Cheyo Jimenez : > >> Thank for thinking of this. I am not sure on the advantage of having nil as >> a concrete type. >> >> Have you seen this talk? >> >> https://realm.io/news/swift-summit-al-skipp-monads

Re: [swift-evolution] [Pitch] Nil struct

> On Nov 8, 2016, at 1:07 PM, Anton Zhilin via swift-evolution > wrote: > > 2016-11-08 23:53 GMT+03:00 Pyry Jahkola >: > > > > Then why not just: > > public protocol ExpressibleByIntLiteral { > static var `nil`: Self > } > > …such that Foo.nil cre

Re: [swift-evolution] [Pitch] Nil struct

2016-11-09 0:12 GMT+03:00 Adrian Zubarev : Could you elaborate an implementation for one of these functions: > func == (left: T?, right: Nil) { switch left { case .some(_): return false case .none: return true } } The implementation is basically the same as of now, except

Re: [swift-evolution] [Pitch] Nil struct

2016-11-09 0:11 GMT+03:00 arkadi daniyelian : I could not clearly see the exact, concrete problem with the current > implementation. IMAO such fundamental change requires a *very* serious > reason and some thought on performance side of thing. > Performance will not be hurt, because as Robert note

Re: [swift-evolution] [Pitch] Nil struct

-1. This type is isomorphic to () from a language-internal perspective and will introduce an extra name for which no useful algorithms can be written against from an external one - which makes the proposal isomorphic to one that introduces a keyword without significant justification. ~Robert W

Re: [swift-evolution] [Pitch] Nil struct

Could you elaborate an implementation for one of these functions: func == (left: T?, right: Nil) … I’m a little confused how these would work, because the types are different and the optional is either .none or .some(T) of type Optional where the other side is Nil. --  Adrian Zubarev Sent wit

Re: [swift-evolution] [Pitch] Nil struct

2016-11-08 23:44 GMT+03:00 Adrian Zubarev : At first glance this doesn’t make any sense to me: > > public protocol ExpressibleByNilLiteral { > associatedtype NilLiteralType = Nil > init(nilLiteral: NilLiteralType) > } > > What’s the need for associatedtype there? > > Shouldn’t it be just like

Re: [swift-evolution] [Pitch] Nil struct

2016-11-08 23:53 GMT+03:00 Pyry Jahkola : Then why not just: > > public protocol ExpressibleByIntLiteral { > static var `nil`: Self > } > > …such that Foo.nil creates your nil value of type Foo? > This proposal is not about creating an alternate syntax for nil as Optional. It’s about

Re: [swift-evolution] [Pitch] Nil struct

2016-11-08 23:43 GMT+03:00 Jose Cheyo Jimenez : Thank for thinking of this. I am not sure on the advantage of having nil as > a concrete type. > > Have you seen this talk? > > https://realm.io/news/swift-summit-al-skipp-monads/ > > "The concept of “nil” does not exist in Swift (despite the existen

Re: [swift-evolution] [Pitch] Nil struct

This is a clean approach but that would not solve the example I mentioned. let document: Document = [ "key" = nil // won't work for the second version of the implementation I mentioned ] Do solve this problem here, I’d need a real Nil type I could extend. extension Nil : MyProtocol { … } Tha

Re: [swift-evolution] [Pitch] Nil struct

If we start from this thought… > Adrian Zubarev wrote: > Shouldn’t it be just like this: > public protocol ExpressibleByNilLiteral { > > init(nilLiteral: Nil) > } Then why not just: public protocol ExpressibleByIntLiteral { static var `nil`: Self } …such that Foo.nil creates yo

Re: [swift-evolution] [Pitch] Nil struct

At first glance this doesn’t make any sense to me: public protocol ExpressibleByNilLiteral { associatedtype NilLiteralType = Nil init(nilLiteral: NilLiteralType) } What’s the need for associatedtype there? Shouldn’t it be just like this: public protocol ExpressibleByNilLiteral { init(nilL

Re: [swift-evolution] [Pitch] Nil struct

Thank for thinking of this. I am not sure on the advantage of having nil as a concrete type. Have you seen this talk? https://realm.io/news/swift-summit-al-skipp-monads/ "The concept of “nil” does not exist in Swift (despite the existence of the keyword nil!)" Does that talk change your mind

[swift-evolution] [Pitch] Nil struct

Gist link Introduction Change nil literal type from () to Nil. Before: public protocol ExpressibleByNilLiteral { init(nilLiteral: ()) } After: public struct Nil { init() } public protocol ExpressibleByNilLiteral { associate