or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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
Have given this a thorough review, both the final proposal, and its development during the draft phases on the list, etc.
Unfortunately I have to give the final proposal as it stands a strong -1.
While I appreciate the future benefits of more generic existential types, the final proposal introduces syntax that is flat-out confusing and inconsistent with the rest of Swift 3.
In Swift, the & operator is not used for composition, it serves only as the “Bitwise AND" operator for integer operations.
OptionSetType gives a good example, where Swift has actively abandoned & for composition. Previously code was in an Obj-C style, e.g.
NSOptionBox & NSOptionCarton
but now uses “,” for composition within an array context:
[.box, .carton]
For this reason, I find that the pattern `<…, …, …>` is still a more Swift-y type composition syntax than the proposal.
+1. It sets the stage for some very desirable type system features in the future. There has already been extensive discussion on the topic and I don’t have anything new to add.
* 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?
No, but I have seen examples from languages that allow this and found them very elegant.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Participated very heavily in the earlier threads on the topic and read the latest proposal.
···
More information about the Swift evolution process is available at
I think I like it and it seems straight-forward enough.
* Is the problem being addressed significant enough to warrant a change to Swift?
I cannot say if it is significant “enough” but I think it results in cleaner looking code that doesn’t end up reading as if generics are being used when they are not.
* Does this proposal fit well with the feel and direction of Swift?
I believe so.
* 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?
Minimal attention-paying during the discussions, 2 readings of the current proposal.
Could this ampersand syntax be reused in protocol adoption too?
Idea:
protocol A { }
protocol B { }
struct Foo : A & B { }
class SuperClass { }
class SubClass : SuperClass, A & B { }
This would solve a problem: currently you cannot tell at a glance whether a
class is a) inheriting from a superclass and adopting one protocol, or b)
adopting two protocols.
Ian Partridge
Hello Swift community,
The review of "SE-0095: Replace `protocol<P1,P2>` syntax with
`Any<P1,P2>`" begins now and runs through June 27. The proposal is
available here:
···
On 22 June 2016 at 19:04, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
or, if you would like to keep your feedback private, directly to the
review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to 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?
+1. This syntax is clean and its meaning is very clear ("what is A & B? A
type that conforms to A and B").
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes, and it's important to address now. As the type system becomes richer
in the future with the completion of generics, combined with Swift's
protocol-driven design philosophies, this feature will get much heavier use
going forward. Having a clean, simple, terse syntax to express multiple
protocol conformances (and eventually concrete type relationships) will
make those features much easier to use without being cluttered by keywords
and potential nested-angle-bracket hell.
The previously proposed Any<...> syntax suffers from ambiguity of meaning:
does it mean "a type that conforms to any of these..." or "any type that
conforms to all of these..."? Turns out it's the latter. The use of "&"
removes that ambiguity completely.
* Does this proposal fit well with the feel and direction of Swift?
Yes. It will go a long way toward making protocol-driven designs and
generics great to use.
* 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?
Read the proposal and participated a small amount in the earlier
discussions.
···
On Wed, Jun 22, 2016 at 11:04 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at
or, if you would like to keep your feedback private, directly to the
review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to 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?
+1. I think this syntax shorter and easier to read.
* 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. It improves the use of protocols in generics and existentials.
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Rust uses `+` with its traits, with basically the same meaning.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal and followed the email threads.
···
On Wed, Jun 22, 2016 at 2:04 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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?
This is a very simple and intuitive way to express compositions that naturally eliminates the ambiguity around ordering which plagued the original proposal
* Is the problem being addressed significant enough to warrant a change to Swift?
It is critical to choose a syntax that will scale up for generalized existentials, which will plug a whole in the current type system.
* Does this proposal fit well with the feel and direction of Swift?
It is new, but fits well with the rest
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Lots... the only real alternative (with the same benefits) is to use ' + '. Given alternatives, swift airs on the side of the easiest to read as English.. which means ' & ' is the natural winner
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Lots, including exploring a generalization that logically degenerates to the syntax prosed here.
More:
···
On Jun 22, 2016, at 8:04 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values <swift/GenericsManifesto.md at main · apple/swift · GitHub, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081 <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>\.\)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
Have given this a thorough review, both the final proposal, and its
development during the draft phases on the list, etc.
Unfortunately I have to give the final proposal as it stands a strong -1.
While I appreciate the future benefits of more generic existential types,
the final proposal introduces syntax that is flat-out confusing and
inconsistent with the rest of Swift 3.
In Swift, the & operator is not used for composition, it serves only as
the “Bitwise AND" operator for integer operations.
OptionSetType gives a good example, where Swift has actively abandoned &
for composition. Previously code was in an Obj-C style, e.g.
NSOptionBox & NSOptionCarton
but now uses “,” for composition within an array context:
[.box, .carton]
The equivalent to [.box, .carton] in Swift 1 option sets would have been
"NSOptionBox | NSOptionCarton", not "&". In that sense, we can't compare
'&' in that context to '&' in this one.
We shouldn't necessarily let analogies to bitwise operations affect us here
because the operations are so dissimilar and clear from context—they only
happen to share the same symbol. The same could be said for addition vs.
string concatenation (and actually has been recently on this list). String
concatenation is formally a multiplicative operation, not an additive one,
and operates on completely different types than numeric ones, but we use +
for historical reasons and because it's clear to the user.
Likewise, the symbol "&" here is quite clear to the user, and I would argue
more so than the protocol<> or Any<> syntaxes (the former because
eventually this may be extended to non-protocol types, and the latter
because it's ambiguous about whether it's "any type conforming to" or "a
type conforming to any of".
···
On Wed, Jun 22, 2016 at 12:34 PM Scott James Remnant via swift-evolution < swift-evolution@swift.org> wrote:
For this reason, I find that the pattern `<…, …, …>` is still a more
Swift-y type composition syntax than the proposal.
Not with this proposal, but this should be allowed at a later point.
This would work as a workaround.
protocol A { }
protocol B { }
typealias AB = A & B
struct Foo : AB { }
class SuperClass { }
class SubClass : SuperClass, AB { }
It’s up to the core team to decide if your mentioned behavior should be allowed with this proposal.
···
--
Adrian Zubarev
Sent with Airmail
Am 22. Juni 2016 um 20:45:55, Ian Partridge via swift-evolution (swift-evolution@swift.org) schrieb:
Could this ampersand syntax be reused in protocol adoption too?
Idea:
protocol A { }
protocol B { }
struct Foo : A & B { }
class SuperClass { }
class SubClass : SuperClass, A & B { }
This would solve a problem: currently you cannot tell at a glance whether a class is a) inheriting from a superclass and adopting one protocol, or b) adopting two protocols.
Ian Partridge
On 22 June 2016 at 19:04, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "SE-0095: Replace `protocol<P1,P2>` syntax with `Any<P1,P2>`" begins now and runs through June 27. The proposal is available here:
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081.)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
This is another way to generalize P&Q compositions that opens another way to specify WHERE
···
On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
We could conceivably bracket the 'where' constraints somewhere. It's nice not to have to punish the common case syntax. In my personal ideal vision of the world, I'd like to see us support opening existentials via path-dependent types (e.g., let a: Collection; let element: a.Element). If we support them in decl-level 'where' clauses, we provide a nice, clean syntax for complex generic relationships that doesn't require angle brackets or per-existential where clauses at all, something like:
which doesn't completely define away the need for 'where' as part of existential types, but would shrink it quite a bit.
-Joe
···
On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081.)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
Thanks for bringing this up. I know one reason we’ve avoided syntax like this in the past is the potential for static subscripts, but of course that’s just one of many future concerns.
Jordan
···
On Jun 23, 2016, at 22:20, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:
Regards
LM
(From mobile)
On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
This is another way to generalize P&Q compositions that opens another way to specify WHERE
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
We could conceivably bracket the 'where' constraints somewhere. It's nice not to have to punish the common case syntax. In my personal ideal vision of the world, I'd like to see us support opening existentials via path-dependent types (e.g., let a: Collection; let element: a.Element). If we support them in decl-level 'where' clauses, we provide a nice, clean syntax for complex generic relationships that doesn't require angle brackets or per-existential where clauses at all, something like:
which doesn't completely define away the need for 'where' as part of existential types, but would shrink it quite a bit.
Would this syntax have the same semantics as the current generics syntax? That would be very cool - it is much more elegant.
···
Sent from my iPad
On Jun 24, 2016, at 6:00 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
-Joe
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081.)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
We could conceivably bracket the 'where' constraints somewhere. It's nice not to have to punish the common case syntax. In my personal ideal vision of the world, I'd like to see us support opening existentials via path-dependent types (e.g., let a: Collection; let element: a.Element). If we support them in decl-level 'where' clauses, we provide a nice, clean syntax for complex generic relationships that doesn't require angle brackets or per-existential where clauses at all, something like:
which doesn't completely define away the need for 'where' as part of existential types, but would shrink it quite a bit.
For some reason it had not clicked until your 'path dependent type' reference how reminicent of (U+00B7) this is. I watched nada's 2014 presentation again... but then it means intersection types would add a lot... you guys seem ok to add P&Q now, so why not take that opportunity to allow P|Q at the same time. Does it also mean that you might consider at some point expanding 'assoctype U' into: T where <:U , :>U opening the door to lower/higher type bounds?
···
On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
-Joe
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081.)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
Thanks for bringing this up. I know one reason we’ve avoided syntax like this in the past is the potential for static subscripts, but of course that’s just one of many future concerns.
I would prefer to simply expand `<...>` to refer to type arguments in general, rather than simply generic arguments, and keep the `Any` syntax. The argument made by a few people in the previous thread that `<...>` is supposedly associated primarily with generics is not compelling to me; it's currently used for protocol composition already, and there are generic features (constrained extensions) that don't use it.
(Consider this my weak -0.5 review against a proposal I helped to author.)
Austin
···
On Jun 24, 2016, at 9:04 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 23, 2016, at 22:20, L. Mihalkovic <laurent.mihalkovic@gmail.com <mailto:laurent.mihalkovic@gmail.com>> wrote:
Originally i wanted to make "[" and "]" be CONSTRAINT_BEGIN and CONSTRAINT_END respectively to signify that what mattered was the overall structure and how it degenerated into this syntax when the composition is not applied to a concrete type (i.e. naked P&Q), as well as show that this gave a formal definition to Any: a zero term composition that is not limited to a single concrete type, otherwise spelled "_ CONSTRAINT_BEGIN CONSTRAINT_END"
Anyhow, it was an interesting mental exercise.
···
On Jun 24, 2016, at 6:04 PM, Jordan Rose <jordan_rose@apple.com> wrote:
On Jun 23, 2016, at 22:20, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:
Regards
LM
(From mobile)
On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081.)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
This is another way to generalize P&Q compositions that opens another way to specify WHERE
Thanks for bringing this up. I know one reason we’ve avoided syntax like this in the past is the potential for static subscripts, but of course that’s just one of many future concerns.
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
We could conceivably bracket the 'where' constraints somewhere. It's nice not to have to punish the common case syntax. In my personal ideal vision of the world, I'd like to see us support opening existentials via path-dependent types (e.g., let a: Collection; let element: a.Element). If we support them in decl-level 'where' clauses, we provide a nice, clean syntax for complex generic relationships that doesn't require angle brackets or per-existential where clauses at all, something like:
which doesn't completely define away the need for 'where' as part of existential types, but would shrink it quite a bit.
For some reason it had not clicked until your 'path dependent type' reference how reminicent of (U+00B7) this is. I watched nada's 2014 presentation again... but then it means intersection types would add a lot... you guys seem ok to add P&Q now, so why not take that opportunity to allow P|Q at the same time. Does it also mean that you might consider at some point expanding 'assoctype U' into: T where <:U , :>U opening the door to lower/higher type bounds?
My point was that the dots (pun intended) are starting to connect and I think it is a neat path to follow. Strike union type as the first use case is already addressed, and it would no matter what be a larger additive. I would love to see a future with type bounds, and although the implementation would be a massive delta, the syntax change would be very minimal. I will play more with my little syntactic exercise to see what a grammar might look like following your train of thoughts.
···
On Jun 25, 2016, at 9:00 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:
On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
-Joe
However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to generalize protocol values, we’re going to want something that’s essentially “a type with a ‘where’ clauses in it”. I really don’t want to force people to use a typealias to spell such a type, but at the same time I want that where clause to be clearly attached to the type. (As brought up before the return position of a function is currently ambiguous with SE-0081.)
Despite the lightweightedness and the well-prepared proposal by Adrian and Austin, the lack of bracketing <> () {} leads me to maintain my stance against the proposed syntax.
Let's not rathole on the P|Q thing. Disjunctions are difficult to make much sense of in a parametric type system like ours; there are plenty of other threads on this mailing list discussing it.
-Joe
···
On Jun 25, 2016, at 12:00 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:
Inline
Regards
(From mobile)
On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
I’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
let callback: (Data) -> NSCoding & NSCopying
but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
We could conceivably bracket the 'where' constraints somewhere. It's nice not to have to punish the common case syntax. In my personal ideal vision of the world, I'd like to see us support opening existentials via path-dependent types (e.g., let a: Collection; let element: a.Element). If we support them in decl-level 'where' clauses, we provide a nice, clean syntax for complex generic relationships that doesn't require angle brackets or per-existential where clauses at all, something like:
which doesn't completely define away the need for 'where' as part of existential types, but would shrink it quite a bit.
For some reason it had not clicked until your 'path dependent type' reference how reminicent of (U+00B7) this is. I watched nada's 2014 presentation again... but then it means intersection types would add a lot... you guys seem ok to add P&Q now, so why not take that opportunity to allow P|Q at the same time. Does it also mean that you might consider at some point expanding 'assoctype U' into: T where <:U , :>U opening the door to lower/higher type bounds?