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

2016-11-09 Thread Karl via swift-evolution
-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

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

2016-11-08 Thread Jose Cheyo Jimenez via swift-evolution
> 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? >> >>

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

2016-11-08 Thread John McCall via swift-evolution
> 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

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

2016-11-08 Thread Anton Zhilin via swift-evolution
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

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

2016-11-08 Thread Anton Zhilin via swift-evolution
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,

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

2016-11-08 Thread Robert Widmann via swift-evolution
-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

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

2016-11-08 Thread Adrian Zubarev via swift-evolution
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

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

2016-11-08 Thread Anton Zhilin via swift-evolution
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

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

2016-11-08 Thread Anton Zhilin via swift-evolution
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

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

2016-11-08 Thread Adrian Zubarev via swift-evolution
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 { … }

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

2016-11-08 Thread Pyry Jahkola via swift-evolution
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

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

2016-11-08 Thread Adrian Zubarev via swift-evolution
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 {

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

2016-11-08 Thread Jose Cheyo Jimenez via swift-evolution
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

[swift-evolution] [Pitch] Nil struct

2016-11-08 Thread Anton Zhilin via swift-evolution
Gist link Introduction Change nil literal type from () to Nil. Before: public protocol ExpressibleByNilLiteral { init(nilLiteral: ()) } After: public struct Nil { init() } public protocol ExpressibleByNilLiteral {