Zig: Proposal: elif

[PavelVozenilek]

Multiple nested if may create "Eiffel tower" in the code:

if (...) {
    func1();
} else {
    if (...) {
      func2();
    } else {
        if (...) {
            func3();
        } else {
            if (...) {
                func4();
            } else {
                func5();
            }
        } 
    }
}

The more intended code gets, the less readable it is.

My proposal is to add elif alternative:

if (...) {
    func1();
} elif (...) {
    func2();
} elif (...) {
    func3();
} elif (...) {
    func4();
} else {
    func5();
}

to reduce intendation.

Notes:

1. I don't know whether it could play nicely with captures. Perhaps the feature should be allowed only for simple checks with no captures.
2. It could be implemented by rewriting at source code level.
3. switch existence is not relevant here.
4. Eiffel tower may be avoided by nonstandard placing of ifs: however this may be against project rules, and nonstandard means confusion.

[Ilariel]

In my opinion this is a bad idea because not only does it break Zig Zen, but because it doesn't actually solve any problems but instead just introduces an alternative way to write "else if" on the same text line and saves 3 characters ("se "). The stylistic issue should not be in the scope of the language and even then if you look at the current documentation. At the if statement examples there is an example using if else:

if (a != b) {
    assert(true);
} else if (a == 9) {
    unreachable
} else {
    unreachable
}

Therefore I think that breaking the core principles of the language just to satisfy arbitrary style guide is a bad thing to do.

[PavelVozenilek]

@Ilariel: yes, by unusual placement of keywords. Project guidelines or personal habits may stand against this. (And judging by common C/C++ code people tend to do the towers.)

if (...) {
  ...
} else if (...) {
   ...
} else {
  ...
}

[Ilariel]

@PavelVozenilek, I edited my rather accidental email reply.

Breaking the Zig Zen:

Only one obvious way to do things

We should then remove "else if" in favor of elif

Minimize energy spent on coding style

Why are we having this discussion and if we really have to argue about coding style we should then implement a mandatory enforced style like go does and everyone who disagrees with the compiler then would just be wrong.

[PavelVozenilek]

@Ilariel:

1. I support disabling else if as bad style.
2. Mandatory enforced style would be a very good thing, if it can be set on per-project basis. Names in stdlib or keywords could convert to desired style, project specific coding rules could be implemented (e.g. trailing ! character meaning predicate functions), etc.

[thejoshwolfe]

I don't get it. Why is else if bad style?

[PavelVozenilek]

@thejoshwolfe: because it could result in over-intended blocks of code.

I tried to find some Eiffel tower in Zig's stdlib to support my argument,
but it systematically uses } else if (...) { idiom, e.g. :

pub fn cmp(a: &const u8, b: &const u8) -> i8 {
    var index: usize = 0;
    while (a[index] == b[index] and a[index] != 0) : (index += 1) {}
    if (a[index] > b[index]) {
        return 1;
    } else if (a[index] < b[index]) {
        return -1;
    } else {
        return 0;
    };
}

in https://github.com/zig-lang/zig/blob/master/std/cstr.zig

Since it is "almost standard", why not to formalize it and reduce the chance to make code less readable?

An alternative could be:

1. _good style_ recommendation in documentation,
2. formatter which would suggest rearranging the tower.

[iology]

An alternative could be: 1. good style recommendation in documentation,

I think else if is a good style.

1. formatter which would suggest rearranging the tower.

Sometimes I would just explicitly write the braces to make the logic clear until I'm sure it is fine to make the last branch else if instead of else { if ... }:

if (...) {
  ...
} else if (...) {
  ...
} else if (...) {
  ...
} else {
  if (...) {
    ...
  }
}

[tiehuis]

One different reason I would disagree with this is based on how other constructs in zig currently work with else statements.

if (a) {
    1
} else if (c == 4) {
    3
} else while (getValue()) |v| {
    if (v == 10) break 4;
} else switch (b) {
    else => 5,
}

I don't think we could replace the else if construct entirely with elif unless we changed all these constructs in a similar vein (which is bad). This would mean we would have two ways of doing the same thing in this case.

Anecdotally, I've never really come across any of this 'eiffel tower' in much code anyway.

[andrewrk]

This proposal doesn't adequately explain the use case for not using else if.