[Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

Austin · June 27, 2016, 5:04pm

I think the rationale thread for the original version of this proposal
pretty much shut down the possibility of disjunctive type constraints. In
fact, the primary argument against '&' was that it would encourage
conversations about '|'.

It's also been added to the commonly rejected proposals list:

github.com

apple/swift-evolution/blob/main/commonly_proposed.md

# Commonly Rejected Changes 

This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://forums.swift.org/t/brace-syntax/678/3): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.

 * [Remove `;` semicolons](https://forums.swift.org/t/proposal-to-remove-semicolons/523/3): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://forums.swift.org/t/change-the-name-of-the-boolean-operators/30/2), and [allow non-punctuation operators](https://forums.swift.org/t/allowing-characters-for-use-as-custom-operators/952) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://forums.swift.org/t/ternary-operator-suggestion/49/148): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

···

On Mon, Jun 27, 2016 at 9:48 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

> 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:
>>>
>>> [Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
]
>>>
>>> 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:
>>
>> func intersect(a: Collection, b: Collection) -> Collection
>> where a.Element == b.Element, b.Element == return.Element {
>> }
>>
>> 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?

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

L_Mihalkovic · June 27, 2016, 5:19pm

Inline

Regards&Apologies
LM
(From mobile)

···

On Jun 27, 2016, at 6:48 PM, Joe Groff <jgroff@apple.com> wrote:

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:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md ]

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:

func intersect(a: Collection, b: Collection) -> Collection
where a.Element == b.Element, b.Element == return.Element {
}

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?

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.

Already retracted the P|Q as bringing absolutely nothing required in the foreseeable future. Apologies again for not having the presence of mind to see it before clicking send.

L_Mihalkovic · June 27, 2016, 7:57pm

As i said, already deeply regretted mentioning P|Q as on closer examination of a well known precedent it is very realistic to have P&Q only.
Apologize again for not doing the due dilligence before pressing send.
(From mobile)

···

On Jun 27, 2016, at 7:04 PM, Austin Zheng <austinzheng@gmail.com> wrote:

I think the rationale thread for the original version of this proposal pretty much shut down the possibility of disjunctive type constraints. In fact, the primary argument against '&' was that it would encourage conversations about '|'.

It's also been added to the commonly rejected proposals list: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

On Mon, Jun 27, 2016 at 9:48 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

> 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:
>>>
>>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md ]
>>>
>>> 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:
>>
>> func intersect(a: Collection, b: Collection) -> Collection
>> where a.Element == b.Element, b.Element == return.Element {
>> }
>>
>> 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?

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution