I guess it would make some people happy, and I would use it myself if rare cases.
The compiler can find the end of blocks by indent, so why not just allow an optional end keyword whenever a block end is detected by the compiler by indent reduction. So allow code like
proc startsWith(s: string; x: varargs[string]): bool =
for i in x:
if s.startsWith(i):
return true
end # optional end if marker
end # optional end for loop marker
end # optional end proc marker
And no, that is not the same as an "# end" line, as the compiler verifies that the end keyword matches the indents. We would use such end keywords only in rare cases, maybe when a proc or loop is very long or for cryptic critical code. Some people may use the end keyword always, maybe when they like code looking like Ruby. Smart editors may even hide lines with end keyword.
And when it is not already clear what the benefit is: Without the end keyword, we can delete two spaces in the last line of a block and generate wrong code. People hating significant whitespace say that invisible characters can change the behaviour of the code. Isn't the end keyword a protection for that?
You can use parenthesis for that.
If we really want to avoid mistake we would need end if end for end proc.
Also I suggest using the indent-rainbow extension https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow (which happen to feature Nim prominently in the demo ;))
We would use such end keywords only in rare cases, maybe when a proc or loop is very long or for cryptic critical code.
I think there will still be a large number of people adding "end". And there will be disagreements because some people like to put "end" and others hate it.
moe is written in Nim. :-) { It could have been called Nim's Own Editor, but "noe" sounds pretty negative. lol ;-) }
Anyway, code has always been 2 dimensional for humans even if algos to analyze it are 1-D character/token streams. The significant whitespace debate has always been a "how much redundancy do you want?" question. With end tokens you have two things to be kept consistent (conditioned upon not being confusing to a human). Some people hate the extra requirement. Some love it. Long before Python copied ABC to drop the requirement, people wrote "pseudo-code" without such "distracting" extras. (One person's "distraction" is another's "check sum".) Before that LISP code writers were encouraged to just "ignore close )s, let the editor do it; Read by indentation". And as @lum says, dropping the requirement does lead to less to fight over in formatting style wars.