error for incorrectly indented code / misleading indentation about zig HOT 13 OPEN

@hryx I think it's important to make this part of the language spec. It makes this example invalid according to the language specification:

if (match_cond)
    x.removeThing(y);
    x.swap(z);

Which means that the above code is not valid Zig.

from zig.

it would be interesting the developer choose between {} and identation level

if (match_cond)
    x.removeThing(y);
    x.swap(z);

// is equivalent to

if (match_cond) {
    x.removeThing(y);
    x.swap(z);
}

if (match_cond)
    x.removeThing(y);
  x.swap(z);

// is equivalent to

if (match_cond) {
    x.removeThing(y);
    x.swap(z);
}

if (match_cond) x.removeThing(y);
    x.swap(z);

// is equivalent to

if (match_cond) {
    x.removeThing(y);
    x.swap(z);
}

if (match_cond) x.removeThing(y); x.swap(z);

// is equivalent to

if (match_cond) {
    x.removeThing(y);
    x.swap(z);
}

if (match_cond)
    x.removeThing(y);
x.swap(z);

// is equivalent to

if (match_cond) {
    x.removeThing(y);
}

x.swap(z);

from zig.

While I agree with the outcome, wouldn't this mean the language becomes whitespace-sensitive for the first time? That is, if this is part of the spec and not just a compiler feature.

It's different from disallowing hard tabs because \t is just an illegal byte. zig fmt accepts and fixes tabs so that the parser can remain simpler, whereas it seems like this will introduce more bookkeeping into the parser.

I wonder if zig fmt or zig fmt --exit-non-zero-when-code-aint-pretty should be in charge of this?

from zig.

this sounds like something that zig fmt should be in charge of. while zig doesn't have warnings,

if (match_cond)
    x.removeThing(y);
    x.swap(z);

seems more appropriate as a warning (or a note) rather than an error, or the sort of thing that should go in a zig style guide.

from zig.

An alternative that would fix this same issue as @iology pointed out: requiring the expression of an if statement to start on the same line as the ) of the if statement

if(…) …; // allowed
if(…)
    …; // not allowed
if(…) ( // allowed
    …
);
if(…) { // allowed
    …
}
if(…)
{ // not allowed

}

and the same with other blocks

for(…) |value, i| …; // allowed
for(…) |value, i|
    …; // not allowed
for(…)
    |value, i| …; // not allowed
for(…) |value, i| { // allowed
    …
}
for(…) |value, i|
{ // not allowed
    …
}

This code would be rejected:

if (match_cond)
    x.removeThing(y);
    x.swap(z);

as it would have to be changed to either

if (match_cond) {
    x.removeThing(y);
    x.swap(z);
}

or

if (match_cond) x.removeThing(y);
x.swap(z);

Current code that uses if expressions may need parenthesis added

const value = if(condition)
    1
else
    2;

→

const value = if(condition) (
    1
) else (
    2
);

Both of these proposals still leave an issue with:

if (match_cond) x.removeThing(y); x.swap(z);

that shouldn't be too difficult to disallow if necessary.

from zig.

My argument agains this, basically "to not make zig space sensitive" is because it would make generating zig code much harder. I am currently generating some zig code from a web gui, and having to handle this would be very cumbersome.

What I propose is to always run zig fmt when compiling, and issuing a warning if the formatting step changed the code. This warning should be configurable into an error in build.zig and command line option.

Finally, my way of writing code is to nearly always uses incorrect indentation and then let the formatter fix it before I commit, if zig fmt cannot correct this anymore because it is a compile error would be a major productivity drawback (I am not sure if you mean that).

from zig.

Quoted from #4294

I'm confident in this decision.

Any reason for the public eyes?

If I have to choose both terseness and safety, I would prefer enforcing brackets on multi-line if(), which is much better for reading code although one may make the same old mistake when writing code and you may wonder wheter it was caused by code reformater or something else.

from zig.

@kuon as andrew points out earlier in the discussion, code generators can simply emit no indentation whatsoever and still abide by this rule.

Your point about zig fmt is important though, and I'd like to see that addressed. I also write code with wildly incorrect formatting, then simply save and let my "format on save" hook fix it, so if zig fmt is unable to fix indentation errors that could slow me down considerably.

from zig.

Prerequisite:

• #17584

from zig.

Is this meant to be implemented for stage1 as well?

from zig.

One non-problem problem: Could this be unfriendly for code generators that output zig code since they have to take care of the identation?

from zig.

No because they can completely omit indentation without breaking this rule. The error only happens if the indentation is incorrectly out dented.

But also, Zig is primarily meant to be a human friendly source format. The use case of generated zig code takes a back seat to human maintenance.

from zig.

Will this also trigger an error when you for example have comments that are indented differently from code?

I see some people suggesting to always have zig fmt run when compiling. This is something I would not like to see happening as zig fmt or any other formatter for that matter do a lot of things that I don't like to see happen to my own code.

from zig.