[swift-evolution] Enhanced existential types proposal discussion

[Dave Abrahams]

on Wed May 18 2016, Thorsten Seitz <swift-evolution at swift.org> wrote:

>> Am 18.05.2016 um 06:52 schrieb Austin Zheng via swift-evolution
>> <swift-evolution at swift.org>:
>> 
>> 
>> 
>
>>> On Tue, May 17, 2016 at 1:25 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>>>>  
>>>>> 
>>>>>> 
>>>>>> Within the angle brackets are zero or more 'clauses'. Clauses
>>>>>> are separated by semicolons. (This is so commas can be used in
>>>>>> where constraints, below. Better ideas are welcome. Maybe it's
>>>>>> not necessary; we can use commas exclusively.)
>>>>> 
>>>>> I’m not a fan of the semicolon idea.  I don’t see any reason for
>>>>> this.  The `where` keyword separates the protocol list from the
>>>>> constraints just fine.  The list on either side should be able to
>>>>> use commas with no problem (or line breaks if that proposal goes
>>>>> through).
>>>> 
>>>> I'm leaning towards getting rid of the commas, but would like to
>>>> write out a few 'dummy' examples to see if there are any
>>>> readability issues that arise.
>>> 
>>> Replaced with what?  Whitespace separation?  I suppose that might
>>> work for the protocol list but it feels inconsistent with the rest
>>> of Swift.  Commas plus (hopefully) the alternative of newline seem
>>> like the right direction to me.
>> 
>> Sorry, I completely misspoke (mistyped?). I meant I want to get rid
>> of the semicolons and use commas. I've come to the conclusion that
>> there are no readability issues, protocol<> already uses commas, and
>> semicolons used in this manner don't have a precedent anywhere else
>> in the language.
>
> Shouldn't there be just a single `where` in the whole `Any<>` clause,
> separating the constraints on the type itself from the constraints on
> associated types?

Normally any type of constraint is allowed after `where`, e.g.

struct X<T : Collection where T : Equatable> {}

FWIW.

-- 
-Dave