Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Am 05. Mai 2016 um 14:59 schrieb Matthew Johnson : Sent from my iPad On May 5, 2016, at 7:30 AM, Thorsten Seitz wrote: To me it reads as a constraint on R. Otherwise we would have to write `protocol R where … : Q where …, S where … { … }`

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPad > On May 5, 2016, at 8:25 AM, David Hart wrote: > >>> Answering Doug’s question: I’d like the name lookup to start in R and to be >>> able to refer to an associated type newly defined in R. >> >> This seems confusing to me. The associated type has not

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

>> Answering Doug’s question: I’d like the name lookup to start in R and to be >> able to refer to an associated type newly defined in R. > > This seems confusing to me. The associated type has not been introduced > until inside the body of R. It doesn't make sense to allow them to be >

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPad > On May 5, 2016, at 7:30 AM, Thorsten Seitz wrote: > > To me it reads as a constraint on R. Otherwise we would have to write > `protocol R where … : Q where …, S where … { … }` which would not only be > confusing but would not make much sense IMHO

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I know why: copy and paste :) Fixed btw. > On 03 May 2016, at 20:25, Dave Abrahams via swift-evolution > wrote: > > > on Mon May 02 2016, David Hart wrote: > >> Hi Doug, >> >> In the latest version of the proposal, which is now linked

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

on Mon May 02 2016, David Hart wrote: > Hi Doug, > > In the latest version of the proposal, which is now linked to a pull request, > I > mentioned in the Detail Design section that the following syntax be > valid: Total nitpick, but I just can't hold it in: I don't

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPad > On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > >> On May 2, 2016, at 3:50 PM, David Hart wrote: >> >> Hi Doug, >> >> In the latest version of the proposal, which is

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone > On May 2, 2016, at 3:50 PM, David Hart wrote: > > Hi Doug, > > In the latest version of the proposal, which is now linked to a pull request, > I mentioned in the Detail Design section that the following syntax be valid: > > protocol R : Q where

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Hi Doug, In the latest version of the proposal, which is now linked to a pull request, I mentioned in the Detail Design section that the following syntax be valid: protocol R : Q where AssocType : P { // … } Can you read through that part of the proposal and let me know if it is descriptive

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Hello Tony, Sorry, I never took the time to comment. I see the issues you are pointing, but they seem to be more generic than only concerning associated type constraints. For example, the "inheritance from non-protocol, non-class type” error also concerns generic types. Perhaps it should be

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

On Fri, Apr 29, 2016 at 4:02 AM, David Hart wrote: > But Collection has to have an extension which explicitly mentions > IndexingIterator: > > extension Collection where Iterator == IndexingIterator { > /// Returns an iterator over the elements of the collection. >

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

But Collection has to have an extension which explicitly mentions IndexingIterator: extension Collection where Iterator == IndexingIterator { /// Returns an iterator over the elements of the collection. public func makeIterator() -> IndexingIterator { return

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

On Fri, Apr 29, 2016 at 1:50 AM, David Hart wrote: > Hi Dimitri, > > Excuse me if I’m being dumb. I saw those example but I don’t understand > their use. > > If I define a custom Collection, I still have the be explicit in the types I > use where associated types are expected.

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Hi Dimitri, Excuse me if I’m being dumb. I saw those example but I don’t understand their use. If I define a custom Collection, I still have the be explicit in the types I use where associated types are expected. Because I need to be explicit, I don’t understand how default associated types

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

On Fri, Apr 29, 2016 at 12:25 AM, David Hart via swift-evolution wrote: > I’ve taken some time to digest the current feedback and I’ve changed my mind. > The syntax for adding constraints to a sub-protocol in the protocol’s > definition where clause is starting to

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

+1 to this! I’ve been missing this as well. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone On Apr 25, 2016, at 10:03 PM, Brent Royal-Gordon wrote: >> Note that, if we do the above, I’d love to make it an error to define a new >> associated type with the same name as an associated type in an inherited >> protocol. It’s odd that we do so,

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

> Note that, if we do the above, I’d love to make it an error to define a new > associated type with the same name as an associated type in an inherited > protocol. It’s odd that we do so, and IIRC the only use case for it is to add > requirement to an “existing” associated type. You also do

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Is that bad? We already have conditional inheritance in classes: class Foo : Bar {} If you move the where clause to the right: class Foo : Bar {} And drop the generic arguments: class Foo : Bar where _constraint_ {} The only difference is “protocol” vs “class”. - Dave

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

On Mon, Apr 25, 2016 at 8:28 PM, Douglas Gregor via swift-evolution wrote: > Did you consider an alternate syntax that puts the where clause outside the > braces, e.g., > > protocol R : Q where AssocType : P { > // … > } To me this reads like declaring a conditional

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

on Mon Apr 25 2016, Dmitri Gribenko wrote: > On Sun, Apr 24, 2016 at 1:34 PM, David Hart via swift-evolution > wrote: >> Currently, associated type declarations can only express simple inheritance >> constraints and not the more

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I really like where this proposal is headed. Would this syntax also support constraining associated types based on "inheritability" (for lack of a better word)? For example, a couple times I've hit a situation where I want to express a supertype/subtype relationship. A contrived example:

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPad > On Apr 25, 2016, at 9:58 AM, Thorsten Seitz wrote: > > >> Am 25.04.2016 um 15:40 schrieb Matthew Johnson via swift-evolution >> : >> >> I really like this proposal. It is a nice step forward from current state. >> >>

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

> Am 25.04.2016 um 15:40 schrieb Matthew Johnson via swift-evolution > : > > I really like this proposal. It is a nice step forward from current state. > > However, it looks like it doesn't allow us to express constraints that elate > two or more associated types

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I really like this proposal. It is a nice step forward from current state. However, it looks like it doesn't allow us to express constraints that elate two or more associated types together, such as requiring both to have the same Element type. I think it would be a good idea to solve the

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

On Sun, Apr 24, 2016 at 1:34 PM, David Hart via swift-evolution wrote: > Currently, associated type declarations can only express simple inheritance > constraints and not the more sophisticated constraints available to generic > types with the where expression. Some

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I’m a strong +1 for this, although I’m suspicious of the timing as in my current project I could do with this right now ;) > On 24 Apr 2016, at 21:34, David Hart via swift-evolution > wrote: > > I wrote the proposal which was discussed to introduce generic

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

+1 I've been missing this myself -Thorsten > Am 25.04.2016 um 04:15 schrieb Rod Brown via swift-evolution > : > > I'm definitely a supporter of this change. It addresses things I've hit > multiple times. > >> On 25 Apr 2016, at 6:34 AM, David Hart via