More Powerful Constraints for Associated Types #284
Conversation
…ft-evolution into associated-types-constraints
|
@lattner @DougGregor I guess you guys must be quite busy, but is there something missing from the proposal holding it from being merged? |
|
We're a bit swamped now, which is why we're so behind on handling PRs. The proposal looks good to me as it is; I'll try to get things merged/numbered soon. |
|
Could this be given a less vague (and preferably sentence-case, which is the most common convention) title, like "Permit |
|
@brentdax I have a hard time finding a title because "Permit where clauses to constrain associated types" is only one part of the story. There is also the new where clause on associated types themselves. |
|
@hartbit I actually think the title I suggested covers both features. In both cases, you're applying a But even if that particular title doesn't cover the entire feature, I think we can come up with something that does. And even if we can't come up with a descriptive title that covers everything, I think a descriptive title that covers a large portion of what's in the proposal is better than a vague title that covers everything. The goal is to make sure that it's easy to pick out this particular feature in proposal listings, subject lines, etc.; a descriptive partial title is better for that purpose. |
|
@brentdax How about "Extend where clauses to constrain associated types"? |
|
@hartbit The problem is, they already do constrain associated types when they're used in generics. "Extend |
|
@brentdax done :) @DougGregor Hi Doug. I'm a bit confused. I understand if you guys are all very busy. But is there a reason that proposals like SE-0099 get written, merged, scheduled and started review under two days while others like this stay unmerged for a month? Is it because this proposal is out of scope for Swift 3? If that's the case, I'm more than happy to postpone it until August. I just feels weird when there is little feedback and the whole merge and schedule process feels very inconsistent. |
|
It's likely out-of-scope for Swift 3, because it will require a bit of work in the type checker. Also, we're trying to get the various syntactic changes into Swift 3 so we don't have these kinds of syntactic tweaks in Swift 4. This proposal is more on the additive side. (Also: @lattner seems to have more time to review/merge proposals than I do, and generics stuff is more in my domain) |
|
Thanks for the explanation :) |
|
|
||
| ## Motivation | ||
|
|
||
| Currently, associated type declarations can only express simple inheritance constraints and not the more sophisticated constraints available to generic types with the `where` clause. Some designs, including many in the Standard Library, require more powerful constraints for associated types to be truly elegant. For example, the `SequenceType` protocol can be declared as follows: |
There was a problem hiding this comment.
- Please hard-wrap lines in markdown. Otherwise diffs start to become very hard to work with.
- s/can/could—if it were supported—/?
There was a problem hiding this comment.
(2) Not entirely sure what you mean?
| # Permit where clauses to constrain associated types | ||
|
|
||
| * Proposal: [SE-XXXX](https://github.com/apple/swift-evolution/blob/master/proposals/XXXX-associated-types-constraints.md) | ||
| * Author(s): [David Hart](http://github.com/hartbit), [Jacob Bandes-Storch](jtbandes@gmail.com), [Douglas Gregor](dgregor@apple.com) |
There was a problem hiding this comment.
Those email address links don't work in Markdown. The template has also changed recently.
* Proposal: [SE-NNNN](NNNN-associated-types-constraints.md)
* Authors: [David Hart](https://github.com/hartbit), [Jacob Bandes-Storch](https://github.com/jtbandes), [Doug Gregor](https://github.com/DougGregor)
* Review Manager: TBD
* Status: **Awaiting review**| threads: | ||
|
|
||
| - [[Completing Generics] Arbitrary requirements in protocols](http://thread.gmane.org/gmane.comp.lang.swift.evolution/14243) | ||
| - [More Powerful Constraints for Associated Types](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15201) |
There was a problem hiding this comment.
Although the Gmane web interface is back those links should be updated.
* [\[Completing Generics\] Arbitrary requirements in protocols](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014667.html)
* [Proposal] More Powerful Constraints for Associated Types
- [Week #1](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015625.html)
- [Week #2](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015753.html)
- [Week #3](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016354.html)There was a problem hiding this comment.
Thanks, will do that asap!
| ``` | ||
|
|
||
| But as Douglas notes himself, that syntax is ambiguous since we adopted the | ||
| generic where clause at the end of declarations of the following proposal: |
There was a problem hiding this comment.
What do you mean by that? Using where instead of where?
| @@ -7,16 +7,24 @@ | |||
|
|
|||
| ## Introduction | |||
|
|
|||
| This proposal seeks to introduce a `where` clause to associated types declarations and improvements to protocol constraints to bring associated types the same expressive power as generic types. | |||
| This proposal seeks to introduce a `where` clause to associated types | |||
There was a problem hiding this comment.
drop the “s” from “types”
| This proposal seeks to introduce a `where` clause to associated types declarations and improvements to protocol constraints to bring associated types the same expressive power as generic types. | ||
| This proposal seeks to introduce a `where` clause to associated types | ||
| declarations and improvements to protocol constraints to bring associated types | ||
| the same expressive power as generic types. |
There was a problem hiding this comment.
I think you mean "as generic type parameters"
| @@ -28,24 +36,36 @@ protocol Sequence { | |||
|
|
|||
| ## Detailed Design | |||
|
|
|||
| First of all, this proposal modifies the grammar for protocols associated types to the following: | |||
| First of all, this proposal modifies the grammar for protocols associated types | |||
There was a problem hiding this comment.
"protocols'" or "a protocol's"
|
|
||
| ```swift | ||
| protocol IntSequence : Sequence where Iterator.Element == Int { | ||
| protocol SomeSequence : Sequence where Iterator.Element == Int { |
There was a problem hiding this comment.
IntSequence was a better name for this example.
|
Just in case anyone is curious what's going on: a review of the standard library found that the addition of this feature would be a significant clean-up for the standard library protocols. This clean-up would change some protocol requirements and the mangled names of most generics involving the Sequence protocol, so it has high ABI impact. |
|
It seem to me that use where keyword is too ambiguous. Even with the proposed new syntax. Since we are building a new protocol with a settled constraint, a "with" instead of "where" keywords looks more precise. It allows us to bring back the simple equal sign "=" (used plfor assignation), which is semantically more accurate than the double equals "==" (used for comparison). protocol IntSequence : Sequence
with Iterator.Element = Internet {
//...
} |
|
@hartbit I have two smallish requests for you:
|
@jcnm I really don't think it is worth adding a new keyword for that. But I suggest you bring it up during the mailing list discussions. @DougGregor I'm on it. |
It has been discussed in multiple threads and here is the final proposal.