[swift-evolution] Enhanced existential types proposal discussion

[Thorsten Seitz]

> 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?
This would be similar to the current use of the `where` clause in generics.

Otherwise it at least looks ambiguous whether a comma separates constraints on associated types from each other or from constraints on the type (it might still be unambiguous for the type checker).

-Thorsten 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/d72c4758/attachment.html>