Re: [swift-evolution] [Discussion] Generic protocols

2016-12-10 14:57 GMT+03:00 Adrian Zubarev : I’m fine with adding features step by step. ;) > > There is no need for an explicit type alias in your > > extension MyStruct : Constructible { … } > > Because Value is already constrained by String. > That was my

Re: [swift-evolution] [Discussion] Generic protocols

I’m fine with adding features step by step. ;) There is no need for an explicit type alias in your extension MyStruct : Constructible { … } Because Value is already constrained by String. 2. Should have it’s own thread because the problem already exists today and is not yet formally solved.

Re: [swift-evolution] [Discussion] Generic protocols

I have to agree with Tino Heth, our aim is to add something basic at first. Although we’d better make sure that we will be able to add other wanted features in the future. How about this plan? 1. Generic protocols without associated types 2. Basic conflict resolution using “dot” syntax

Re: [swift-evolution] [Discussion] Generic protocols

> It seems like a lot of you are just trying to make different syntaxes for > generic protocols, which I’m pretty sure was never the concern about them? We > already have reasonable prior art here from the syntax of generic structs. yeah, this discussion has gotten much bigger than I expected:

Re: [swift-evolution] [Discussion] Generic protocols

Hi Anton and welcome back to the discussion. :) While trying to find the talk about overlapping protocol members from different protocols I spotted your proposal: https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md Just one hint, inside an

Re: [swift-evolution] [Discussion] Generic protocols

> On Dec 9, 2016, at 9:21 PM, Alexis via swift-evolution > wrote: > > I’m also pretty confident that allowing protocols to be multi-conformed > without requiring some specific annotation on them is totally busted. The > fact that you can uniquely determine the

Re: [swift-evolution] [Discussion] Generic protocols

It seems like a lot of you are just trying to make different syntaxes for generic protocols, which I’m pretty sure was never the concern about them? We already have reasonable prior art here from the syntax of generic structs. The problem is that they add significant additional complexity to

Re: [swift-evolution] [Discussion] Generic protocols

A fundamental problem is, how do we get rid of associatedtype duplicates? A pedantic approach is to add trait operations for conformances: protocol Constructible { associatedtype Value init(_ value: Value) } struct MyStruct { conformance Constructible { rename associatedtype

Re: [swift-evolution] [Discussion] Generic protocols

I’m not in a rush. Right now I’m just bike shedding here and there. The problem with typealias I see is, that it really is a type alias and not a new type I’d want it to be. Or am I wrong here? I’m curious what some of the core team would say on something like typealias GenericProto = Proto

Re: [swift-evolution] [Discussion] Generic protocols

Does not this make associatedtype redundant additional complexity? On Tue, 6 Dec 2016 at 16:35 Martin Waitz wrote: > Am 2016-12-06 15:01, schrieb Daniel Leping via swift-evolution: > > > > ConstructibleFromValue > > > > Sounds way better to me than the second option

Re: [swift-evolution] [Discussion] Generic protocols

Am 2016-12-06 15:01, schrieb Daniel Leping via swift-evolution: ConstructibleFromValue Sounds way better to me than the second option considering we can't do just ConstructibleFromValue Because of lack of order of associated types. So IMO either we introduce order or we use == syntax. we

Re: [swift-evolution] [Discussion] Generic protocols

ConstructibleFromValue Sounds way better to me than the second option considering we can't do just ConstructibleFromValue Because of lack of order of associated types. So IMO either we introduce order or we use == syntax. Maybe somebody has more ideas of a better syntax? On Tue, 6 Dec 2016 at

Re: [swift-evolution] [Discussion] Generic protocols

What makes me worry is if this syntax is really the best one possible: typealias ConstructibleFrom = ConstructibleFromValue where ValueType == V I find it strange that such exact line with typealias and where is required. I was hoping for an expression that lets us specialize a protocol and use

Re: [swift-evolution] [Discussion] Generic protocols

Guys, I think we've got quit some positive feedback for this. Maybe it's time to go to proposal stage? I personally will back it 100%. If there is anything to add at this stage? On Mon, 5 Dec 2016 at 21:46 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Syntactic sugar

Re: [swift-evolution] [Discussion] Generic protocols

Syntactic sugar could only solve the first issue because it would create a generic type that allows you to reuse your protocol with associated types in a way like ConstructibleFromValue would. The idea is simple, but there are a few disadvantages that makes it less worth to implement. If I

Re: [swift-evolution] [Discussion] Generic protocols

I'm not sure I understand. The first feature in the generics manifesto is parameterized protocols so that you can have, say, ConstructibleFrom and ConstructibleFrom and the ability to conform to the same protocol in two ways. The second feature is explained as a request for generalized

Re: [swift-evolution] [Discussion] Generic protocols

protocol Foo { associatetype Inner : SomeOtherProtocol } // Assuming String and Int conforms to SomeOtherProtocol protocol StringFoo : Foo where Inner == String {} protocol IntFoo : Foo where Inner == Int {} On Sat, Dec 3, 2016 at 13:57 Adrian Zubarev wrote: >

Re: [swift-evolution] [Discussion] Generic protocols

To which code ‘above’ do you refer exactly? --  Adrian Zubarev Sent with Airmail Am 3. Dezember 2016 um 20:29:05, Xiaodi Wu (xiaodi...@gmail.com) schrieb: On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution wrote: @Adrian, my comments inline below.

Re: [swift-evolution] [Discussion] Generic protocols

On Sat, Dec 3, 2016 at 12:02 PM, Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > @Adrian, my comments inline below. Hope this helps. > > On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev < > adrian.zuba...@devandartist.com> wrote: > >> There is one thing that I want to point

Re: [swift-evolution] [Discussion] Generic protocols

@Adrian, my comments inline below. Hope this helps. On Sat, Dec 3, 2016 at 6:22 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > There is one thing that I want to point out with pitched syntactic sugar. > GenericMyProtocolName will also let you reuse T within a generic type, >

Re: [swift-evolution] [Discussion] Generic protocols

There is one thing that I want to point out with pitched syntactic sugar. GenericMyProtocolName will also let you reuse T within a generic type, where currently we cannot nest protocols into types. Even if we could, it’s not clear if nested declarations like protocol MyTProtocolName :

Re: [swift-evolution] [Discussion] Generic protocols

In general I'm very positive with the idea of generic protocols. This discussion is more about syntactic sugar, though I really like where it goes. Off topic: IMO, we should revisit approaches others already use for conflicts resolution. I personally tend to get something similar to Scala traits.

Re: [swift-evolution] [Discussion] Generic protocols

If I’m not mistaken here, extension Foo where T == Int will have an error of redeclaration foo anyways. --  Adrian Zubarev Sent with Airmail Am 3. Dezember 2016 um 15:22:56, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: extension Foo where T == Int { func foo() {

Re: [swift-evolution] [Discussion] Generic protocols

This is a different problem that protocols have today. There was some talk about having some sort of keyword like implements to disambiguate which from where the implementation comes from. Just pretend for a second, we wouldn’t have generic protocols and implement it the SE–01242 way:

Re: [swift-evolution] [Discussion] Generic protocols

> Why don’t we just use angle brackets to specify associated types? Protocols > aren’t using them for anything anyway. You normally don't want to specify all associated types that way — if you had to, Array would be declared like struct Array: SomeSequenceProtocol,

Re: [swift-evolution] [Discussion] Generic protocols

Ok. Let's say I have a generic protocol P with two methods: func foo() func bar(o:T) I have a default implementation of foo, which internally calls bar. How would work foo once a class implements P and P? On Sat, 3 Dec 2016 at 15:26 Adrian Zubarev via swift-evolution <

Re: [swift-evolution] [Discussion] Generic protocols

I believe generic protocols could be used as a shortcut for protocols with associated types. // Protocol with associated type protocol Foo { associatedtype F func foo(_ f: F) } // Existential typealias IntFoo = Any where F == Int struct Test : IntFoo {} // error struct Test :

Re: [swift-evolution] [Discussion] Generic protocols

This is called generalized existentials. It is included in the Generic Manifesto, has been discussed quite a few times with long email chains before, and spawned the change to the `protocol<>` syntax as kinda a precursor. It would be surprised if Swift 4 Phase 2 doesn't have it given its

Re: [swift-evolution] [Discussion] Generic protocols

Love it. I have one concern, though. How do we resolve conflicting associated types once several protocols get applied to a class or a struct? On Sat, 3 Dec 2016 at 11:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > I think I might found a solution that will satisfy

Re: [swift-evolution] [Discussion] Generic protocols

I think I might found a solution that will satisfy generic protocols and not break the system. The generics manifesto shows two features that are requested from generic protocols. The first feature is needed to reuse the same protocol multiple types like struct A : Proto, Proto. With SE–0142

Re: [swift-evolution] [Discussion] Generic protocols

> On Dec 2, 2016, at 12:34 PM, Adrian Zubarev via swift-evolution > wrote: > > I just overlooked that the subsection about generic protocols was inside the > Unlikely section. > > The problem is that I need a way to refer to a function with a specific name. > Plus

Re: [swift-evolution] [Discussion] Generic protocols

Your problem is that you want to conform to the same protocol twice. I've discussed ideas for how to support something like that. I'm not sure if it fits the core team's direction for swift. Karl > > On Dec 2, 2016 at 7:34 pm,

Re: [swift-evolution] [Discussion] Generic protocols

I just overlooked that the subsection about generic protocols was inside the Unlikely section. The problem is that I need a way to refer to a function with a specific name. Plus the connection type has to have a specific API, like having a DispatchQueue and know the router object if there is

Re: [swift-evolution] [Discussion] Generic protocols

Check out the thread called: How to rewrite this snippet without existentials? On some classes I want to write something like this: enum X {…} enum Y {…} class A : Connection, Connection { … } let a = A() let router = Router() router.register(a) --  Adrian Zubarev Sent with Airmail Am 2.

Re: [swift-evolution] [Discussion] Generic protocols

Could you, please, bring a code example? On Fri, 2 Dec 2016 at 19:31 Adrian Zubarev wrote: > The problem I bumped into is, that I cannot overload a function which uses > an associated type, so I could pass that instance to different type which > needs the other

Re: [swift-evolution] [Discussion] Generic protocols

The problem I bumped into is, that I cannot overload a function which uses an associated type, so I could pass that instance to different type which needs the other overloaded function. Only generic protocols could do this. Something similar is described as the top of the Generic protocols

Re: [swift-evolution] [Discussion] Generic protocols

Aren't protocols generic already using associatedtype? Also, what I really would like to have is generic associatedtype. Basically to work the very same way as typealias. Another nice to have feature might be having a possibility to add the same generic protocol several times with different type

[swift-evolution] [Discussion] Generic protocols

Hi there, I wanted to ask if we need generic protocols in stage one or is it something for stage two? I literally bumped into a corner where I need them to write a nice and type safe API. --  Adrian Zubarev Sent with Airmail___ swift-evolution mailing