Re: [swift-evolution] [Proposal] Type Narrowing

> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > This looks like a lot of complexity for very little gain. > > Aside from any implementation concerns, this proposal substantially increases > the cognitive load on developers. To

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? >> >>

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

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

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,

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

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

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

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

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 { … }

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

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 {

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

[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 {

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 8, 2016, at 7:44 AM, Joe Groff via swift-evolution > wrote: >> On Nov 7, 2016, at 3:55 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon Nov 07 2016, John McCall wrote: >> On Nov 6,

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 7, 2016, at 4:59 PM, Dave Abrahams wrote: > on Mon Nov 07 2016, John McCall wrote: > >>> On Nov 7, 2016, at 3:55 PM, Dave Abrahams via swift-evolution >>> wrote: >>> on Mon Nov 07 2016, John McCall wrote: >>>

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 7, 2016, at 3:55 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Nov 07 2016, John McCall wrote: > >>> On Nov 6, 2016, at 1:20 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] [Proposal] Type Narrowing

If I correctly understand the proposal, I'm -1 on this. (1) You can define different methods with the same name on T and Optional (description is such an example). Then what does this do? // someMethod is defined both for T and T? // var foo: T? if foo != nil { foo.someMethod() } I say

Re: [swift-evolution] [Proposal] Type Narrowing

> On 7 Nov 2016, at 19:31, Charlie Monroe wrote: > There are two cases: > > if foo != nil { > foo!.doSomething() > } > > Currently, accessing a non-optional value with ! produces an error: > > let foo = Bar() > foo!.doSomething() // ERROR > > Second: > > if