[Review] SE-0142: Permit where clauses to constrain associated types


(Douglas Gregor) #1

Hello Swift community,

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/pull/532#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager


(Austin Zheng) #2

* What is your evaluation of the proposal?

+1. I very much want to see this in Swift, and it seems like a logical
progression that has the potential to eliminate ugly workarounds.

* Is the problem being addressed significant enough to warrant a change to
Swift?

Yes. Right now the desired relationships between the associated types of a
protocol must be written out at each site of use (for example, a generic
function declaration that involves that protocol type). When defining a
type that conforms to such a protocol these relationships must either be
discovered through documentation, or by examining the APIs with which the
conforming type will be used.

By changing this implicit contract (through documentation + use site
constraints) into an explicit contract (through constraints directly
expressed at the point where the associated types are defined), programmers
seeking to write conforming types have an easier time understanding how the
protocols they are conforming to are intended to work, and programmers
seeking to write APIs involving those protocols don't need to spell out the
constraints repeatedly.

* Does this proposal fit well with the feel and direction of Swift?

Yes. We already have a pretty regular regime for the use of `where` to
define constraints, for example in generic type and function declarations
and when defining constrained extensions. Adding support for `where` to
associated types would be a natural extension of the existing ability to
specify protocol conformance, and its semantics would not be surprising to
those familiar with the other uses of `where`. (This comment I think
applies to all three of the proposed syntaxes.)

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

n/a

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the review, followed most of the pertinent threads over the past few
months with varying degrees of attentiveness.


(Haravikk) #3

What is your evaluation of the proposal?

+1, like others I would love to have this feature available today, as my code is currently littered with complicated constraints on types that could be much more elegantly handled by constraints on the associated types themselves.

Is the problem being addressed significant enough to warrant a change to Swift?

Definitely, this seems like an important next step for Swift's support of generics and constraints.

Does this proposal fit well with the feel and direction of Swift?

Yes, absolutely.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've read through it fairly quickly, but I feel I already have a pretty good grasp of what the feature entails as it solves a problem I encounter often!


(Matt Whiteside) #4

+1. Very much looking forward to the richness this will add to the generic system.

-Matt

···

On Sep 23, 2016, at 16:50, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/pull/532#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Drew Crawford) #5

This is the #1 Swift feature I have wanted for the past 2 years.

One thing I would like to see (perhaps out of scope for this proposal) is the natural extension for generic parameters:

struct Box<T> {
var t: T
}

extension Box where T == Int { //error: Same-type requirement makes generic parameter T non-generic
}

There is a great deal of overlap between associated types and generic parameters, and it seems to me that it would be favorable to allow `==` with both generic parameter operands and associatedtype operands for consistency.

Drew

···

On September 23, 2016 at 6:51:51 PM, Douglas Gregor (dgregor@apple.com) wrote:

Hello Swift community,

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Matthew Johnson) #6

What is your evaluation of the proposal?

+1. This is a great enhancement that I have wanted ever since Swift was released.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes. It allows us to express our intentions much more clearly and concisely.

Does this proposal fit well with the feel and direction of Swift?

Very much.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read, but also a long-time desire to see exactly this feature added to the language.


(Howard Lovatt) #7

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md

What is your evaluation of the proposal?

It is a valuable addition to Swift and certainly something I have desired. However I feel the proposed syntax is long winded, something associated types already suffer from. There also seems to be an inconsistency in specifying constraints sometimes in where clauses and other times as a constraint on the associated type.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes

Does this proposal fit well with the feel and direction of Swift?

Not quite. See above.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

It is similar to generics and begs the question why not abandon associated types and just have generics on protocols.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Mainly my comments are based on writing my own collection library in Swift and comparing that exercise to similar in Java and C++. It is at the moment significantly harder than in Java but easier than C++. Any improvement in associated types would be welcome.


(Nate Cook) #8

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md

What is your evaluation of the proposal?

[Smiling Face With Heart-Shaped Eyes Emoji]

One of the examples given (associatedtype SubSequence : Sequence where SubSequence...) looks like it would run afoul of the (current?) limitations on recursive protocols. Have those been resolved, or is resolving that part of the work of this change?

Other than that question, I give this the heartiest +1 I can muster!

Is the problem being addressed significant enough to warrant a change to Swift?

Definitely—this will have significant effects on not only the standard library itself, but also extensions written by developers using Swift.

Does this proposal fit well with the feel and direction of Swift?

Yes!

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've read the proposal and wrestled many times with extensions that require several annoyingly unnecessary `where` clauses.

Nate


(Dave Abrahams) #9

What is your evaluation of the proposal?

It's ought to be obvious, but +1; when can I have it?

Is the problem being addressed significant enough to warrant a change
to Swift?

Indeed.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

I haven't, except maybe Haskell.

How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

All that and more.

Cheers,

···

on Fri Sep 23 2016, Douglas Gregor <swift-evolution@swift.org> wrote:
--
-Dave


(Karl) #10

What is your evaluation of the proposal?

+1. Can’t wait.

···

Is the problem being addressed significant enough to warrant a change to Swift?

-_-

Does this proposal fit well with the feel and direction of Swift?

Sure does

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the generics manifesto carefully, often wanted this feature, read the proposal carefully.


(David Sweeris) #11

+111eleventyone
Also, FWIW, strong +1 for everything in the generics manifesto, too.

···

Sent from my iPhone

On Sep 23, 2016, at 18:50, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Lily Ballard) #12

* What is your evaluation of the proposal?

+1. This looks like a great addition.

I'm not fond of the shorthand syntax in the Alternatives section though

* Is the problem being addressed significant enough to warrant a
   change to Swift?

Yes.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?

Nothing comes to mind.

* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

A quick reading.

-Kevin Ballard

···

On Fri, Sep 23, 2016, at 04:50 PM, Douglas Gregor wrote:


(Hooman Mehr) #13

Strong +1. I really need this feature to improve and simplify my existing code.

···

On Sep 23, 2016, at 5:50 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

+1. I very much want to see this in Swift, and it seems like a logical progression that has the potential to eliminate ugly workarounds.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Right now the desired relationships between the associated types of a protocol must be written out at each site of use (for example, a generic function declaration that involves that protocol type). When defining a type that conforms to such a protocol these relationships must either be discovered through documentation, or by examining the APIs with which the conforming type will be used.

By changing this implicit contract (through documentation + use site constraints) into an explicit contract (through constraints directly expressed at the point where the associated types are defined), programmers seeking to write conforming types have an easier time understanding how the protocols they are conforming to are intended to work, and programmers seeking to write APIs involving those protocols don't need to spell out the constraints repeatedly.

* Does this proposal fit well with the feel and direction of Swift?

Yes. We already have a pretty regular regime for the use of `where` to define constraints, for example in generic type and function declarations and when defining constrained extensions. Adding support for `where` to associated types would be a natural extension of the existing ability to specify protocol conformance, and its semantics would not be surprising to those familiar with the other uses of `where`. (This comment I think applies to all three of the proposed syntaxes.)

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the review, followed most of the pertinent threads over the past few months with varying degrees of attentiveness.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jens Persson) #14

Strong +1

···

On Sat, Sep 24, 2016 at 9:36 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

   - What is your evaluation of the proposal?

+1, like others I would love to have this feature available today, as my
code is currently littered with complicated constraints on types that could
be much more elegantly handled by constraints on the associated types
themselves.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

Definitely, this seems like an important next step for Swift's support of
generics and constraints.

   - Does this proposal fit well with the feel and direction of Swift?

Yes, absolutely.

   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

I've read through it fairly quickly, but I feel I already have a pretty
good grasp of what the feature entails as it solves a problem I encounter
often!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matt Whiteside) #15

I also wanted to throw in support for Drew’s addendum below. It’s a feature I’ve come across the need more than once, and I don’t even write a lot of swift.

-Matt

···

One thing I would like to see (perhaps out of scope for this proposal) is the natural extension for generic parameters:

struct Box<T> {
    var t: T
}

extension Box where T == Int { //error: Same-type requirement makes generic parameter T non-generic
}

There is a great deal of overlap between associated types and generic parameters, and it seems to me that it would be favorable to allow `==` with both generic parameter operands and associatedtype operands for consistency.

Drew


(TJ Usiyan) #16

What is your evaluation of the proposal?
    +1
Is the problem being addressed significant enough to warrant a change to
Swift?
    Yes. A thousand times yes.
Does this proposal fit well with the feel and direction of Swift?
    Yes.
If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
    It compares well. Same type requirements for generic parameters are
sorely missed though.
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
    I've followed the discussion closely and given input a couple times.

More information about the Swift evolution process is available at

···

On Sun, Sep 25, 2016 at 6:39 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Fri Sep 23 2016, Douglas Gregor <swift-evolution@swift.org> wrote:

> What is your evaluation of the proposal?

It's ought to be obvious, but +1; when can I have it?

> Is the problem being addressed significant enough to warrant a change
> to Swift?

Indeed.

> Does this proposal fit well with the feel and direction of Swift?

Yes.

> If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?

I haven't, except maybe Haskell.

> How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?

All that and more.

Cheers,
--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #17

This is the #1 Swift feature I have wanted for the past 2 years.

One thing I would like to see (perhaps out of scope for this proposal) is the natural extension for generic parameters:

struct Box<T> {
    var t: T
}

extension Box where T == Int { //error: Same-type requirement makes generic parameter T non-generic
}

There is a great deal of overlap between associated types and generic parameters, and it seems to me that it would be favorable to allow `==` with both generic parameter operands and associatedtype operands for consistency.

Drew

I think this is already part of the Generics Manifesto: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

Concrete same-type requirements

Currently, a constrained extension cannot use a same-type constraint to make a type parameter equivalent to a concrete type. For example:

extension Array where Element == String {
  func makeSentence() -> String {
    // uppercase first string, concatenate with spaces, add a period, whatever
  }
}
This is a highly-requested feature that fits into the existing syntax and semantics. Note that one could imagine introducing new syntax, e.g., extending Array<String>, which gets into new-feature territory: see the section on "Parameterized extensions".

- Karl

···

On 24 Sep 2016, at 21:58, Drew Crawford via swift-evolution <swift-evolution@swift.org> wrote:
On September 23, 2016 at 6:51:51 PM, Douglas Gregor (dgregor@apple.com <mailto:dgregor@apple.com>) wrote:

Hello Swift community,

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/pull/532#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Douglas Gregor) #18

This is the #1 Swift feature I have wanted for the past 2 years.

One thing I would like to see (perhaps out of scope for this proposal) is the natural extension for generic parameters:

struct Box<T> {
    var t: T
}

extension Box where T == Int { //error: Same-type requirement makes generic parameter T non-generic
}

There is a great deal of overlap between associated types and generic parameters, and it seems to me that it would be favorable to allow `==` with both generic parameter operands and associatedtype operands for consistency.

Yeah, we should allow this. I think it's in the generics manifesto as well, and Slava Pestov has been making great progress toward unblocking the feature. I do think it's a separate proposal.

  - Doug

···

Sent from my iPhone

On Sep 24, 2016, at 12:58 PM, Drew Crawford via swift-evolution <swift-evolution@swift.org> wrote:

Drew

On September 23, 2016 at 6:51:51 PM, Douglas Gregor (dgregor@apple.com) wrote:

Hello Swift community,

The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Douglas Gregor) #19

https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md

What is your evaluation of the proposal?

[Smiling Face With Heart-Shaped Eyes Emoji]

One of the examples given (associatedtype SubSequence : Sequence where SubSequence...) looks like it would run afoul of the (current?) limitations on recursive protocols. Have those been resolved, or is resolving that part of the work of this change?

That's a good point. Recursive protocols are a separate feature we've had on our wish list for Swift 4, because they can be used to clean up a bunch of ugliness in the standard library. Perhaps this proposal should change its example that doesn't depend on that not-yet-implemented feature.

  - Doug

···

Sent from my iPhone

On Sep 24, 2016, at 6:55 PM, Nate Cook <natecook@gmail.com> wrote:

Other than that question, I give this the heartiest +1 I can muster!

Is the problem being addressed significant enough to warrant a change to Swift?

Definitely—this will have significant effects on not only the standard library itself, but also extensions written by developers using Swift.

Does this proposal fit well with the feel and direction of Swift?

Yes!

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've read the proposal and wrestled many times with extensions that require several annoyingly unnecessary `where` clauses.

Nate


(Drew Crawford) #20

I think this is already part of the Generics Manifesto: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

So is this proposal. The proposal's "Motivation" is lifted from the Arbitrary Requirements in Protocols section: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#arbitrary-requirements-in-protocols-