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

[Etan Kissling]

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<mailto: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<mailto: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<mailto:swift-evolution at swift.org>> wrote:


On Dec 12, 2015, at 5:41 AM, Al Skipp via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:

On 12 Dec 2015, at 13:31, Marc Knaup via swift-evolution <swift-evolution at swift.org<mailto: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<mailto:gparker at apple.com>     Runtime Wrangler



_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto: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/52f7c949/attachment.html>