[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses
Erica Sadun
erica at ericasadun.com
Fri May 27 14:50:50 CDT 2016
On May 27, 2016, at 1:47 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>
>>
>> On May 27, 2016, at 2:37 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>> Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked up examples, it felt less readable and I suspect it would negatively affect the clarity of parsing this proposal aims to introduce.
>
> Maybe Joe can comment on the parsing question.
>
> What kinds of examples did you look at where you felt that way? IMO the example in the proposal reads better without the semicolons:
>
> guard
> x == 0;
> let y = optional;
> z == 2
> else { ... }
>
> vs
>
> guard
> x == 0
> let y = optional
> z == 2
> else { ... }
>
>
I think this is going to be a matter of taste. I do not prefer the second example.
>>
>> I'd really like to see a separate newline-as-separator proposal brought forward and formally reviewed. It's garnered a few very vocal supporters but it really doesn't fall under the umbrella of this proposal. I'd like the matter to be settled one way or the other for the sake of closure.
>
> The other discussion has been about introducing newline-as-separator for comma separated lists.
>
> I raised the question in my review because Swift already uses newline-as-separator for semicolon separated lists (statements).
If the guard elements were in a braced scope, I might feel differently. I prefer the form that is presented.
-- E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/31fc345b/attachment.html>
More information about the swift-evolution
mailing list