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

[Marc Knaup]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/e6538e18/attachment.html>