[swift-evolution] Optional "endfor", "endif", etc after closing "}"

[Andrew Bennett]

I agree with Stephen, I think it will probably just make more clutter.
However if you did want to do it a linter is probably a better option.

I haven't used it yet, but I've heard this one is good:
 * https://github.com/realm/SwiftLint
 * Another alternative: http://swiftcleanapp.com

Among other really things it would allow you to enforce style choices on
your code. You could make it a compile time error if an if-statement wasn't
followed by a "} // if".

I'm not sure about the second tool, but you can add custom rules to the
first. This may be a good starting point:
https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/ControlStatementRule.swift




On Tue, Dec 15, 2015 at 12:22 AM, Etan Kissling via swift-evolution <
swift-evolution at swift.org> wrote:

> That's why I've included the "case ... where" case :) condition3 is only
> evaluated after 1/2.
>
> On 14 Dec 2015, at 12:59, Marc Knaup <marc at knaup.koeln> wrote:
>
> This changes the behavior though.
>
> In "if cond1 && cond2" cond2 is only evaluated iff cond1 is true.
> Using switch both conditions will be evaluated right away unconditionally.
>
> On Mon, Dec 14, 2015 at 12:48 PM, Etan Kissling via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Counter-proposal that eliminates the nested ifs.
>>
>> If I have functions with long if blocks, I typically use switches on
>> named tuples.
>>
>> switch (condition1: ..., condition2: ...) {
>>     case (condition1: false, condition2: true):
>>         ...
>>
>>     case (condition1: _, condition2: false):
>>         ...
>>
>>     case (condition1: true, condition2: true) where condition3:
>>         ...
>>
>>     case (condition1: true, condition2: true):
>>         ...
>> }
>>
>> This way, you are reminded after each long block about your current
>> scope, and the compiler checks for unhandled cases.
>>
>> Etan
>>
>>
>> On 12 Dec 2015, at 22:35, Greg Parker via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Dec 12, 2015, at 5:41 AM, Al Skipp via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> On 12 Dec 2015, at 13:31, Marc Knaup via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I'm also against any kind of markers to annotate the end of a block.
>>
>> If the code inside a if/guard/loop/do/func/var/… block is so long that
>> the developer thinks about annotating the closing curly brace then they
>> should instead break it down into smaller pieces. Move parts into separate
>> functions and replace it with calls to these functions.
>> This makes the block shorter, much easier to understand and the function
>> names will aid as additional documentation.
>>
>>
>> I completely agree.
>>
>> If code becomes so impenetrable that you need to annotate the end of
>> blocks to assist comprehension, then the code needs refactoring.
>>
>>
>> Or a better editor. Modern code editors have affordances to improve
>> readability of such code, such as highlighting matching braces, coloring
>> nested scopes, or folding and unfolding scopes.
>>
>> One advantage of the editor-based approaches is that they don't make
>> editing more difficult. You don't need to write any scope annotations and
>> you don't need to keep them up to date as the code changes.
>>
>>
>> --
>> Greg Parker     gparker at apple.com     Runtime Wrangler
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/85d730d1/attachment.html>