4 ms·
That's a fair point. It's the reason that I've marked significant whitespace as "experimental" in the documentation. Since the language is in an early stage, I
by nickmqb 8y ago
That's a fair point. It's the reason that I've marked significant whitespace as "experimental" in the documentation. Since the language is in an early stage, I think it's OK to try some slightly more experimental constructs for now. The feature does provide some nice benefits in terms of parsing robustness, which is really noticeable especially when working with live error feedback (i.e. language server, coming soon).
But rest assured, this is very much on my radar! If it turns out to be too much of a pain, I'll remove it (or make it opt in). Fortunately, because of the redundant braces the transition would be seamless: we can just drop the whitespace requirement.
- ahaferburg 8y agoI actually think that this is pretty close to the sweet spot. You make line breaks significant, but not the indentation level. The indentation will be inferred automatically from the braces. That way you can paste code that has the wrong indentation, hit save, and as long as the braces are balanced, the indentation will get fixed automatically by an auto-formatter. I would be very interested to know how happy Python programmers are with the indentation level being significant. Did Guido ever say anything about it?
- newen 8y agoWow that's amazing. Now you'll finally be able to do what's been possible to do in C since the dawn of time.
- lgas 8y agoI worked almost exclusively in python for about five years and loved significant whitespace. It was one of the things I missed most when working in other languages. Now I work primarily in Haskell which has significant whitespace with optional braces and I still love significant whitespace and never use the brace style. In practice I found the copy/paste problem exceedingly rare to the point that it has been completely a non-issue in both languages.
- IshKebab 8y agoI think it's a great idea. I think you could perhaps reword it to make things a bit less weird sounding though: blocks are created using curly brackets, but correct indentation is enforced by the compiler. Indenting weirdly (e.g. mixing spaces/tabs) will cause a compile error. Also I can't see how it would affect code sharing at all. I assume it is per-file, so adding entire files won't matter, and if you have a project that wants to steal a bit of code from another in one file, surely you want to convert their indentation to yours - which would be trivial to do given that you enforce correct indentation. I think it is a good idea. If you ban tabs you'll piss off the sane 50% of programmers, and if you ban spaces you'll piss off the other 50%. Allowing either but with no mixing makes sense. The only exception I can think of is that some people like to do tabs for indentation and spaces for alignment. Dunno if you could support that easily...
- nickmqb 8y agoWith regards to your last point, that would be fine. The compiler doesn't care about spaces vs tabs after the first non-whitespace character of a line, as that's not relevant to how the code is parsed.
- irq-1 8y agoLook at how much of this discussion is on formatting, and it's the top threads. Make a "mufmt" with zero options and let everyone focus on important things.