The limits of {braced} comments.

Phil Pilgrim (PhiPi)

Braces can be useful for commenting out large swaths of code, but they're not foolproof. Here's an example where they fail:

{a := string("ab}")}

The original code had a right brace within quotes. Once code is commented out, though, the quotes have zero syntactical significance, so the quoted right brace becomes the comment terminator, leading to an error.

Not everything within braces is insignificant, however. Did you know that braces can be nested? The compiler keeps track of the nesting level during parsing, requiring that they be balanced.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

hippy

I don't think there's anyway round that or that any compiler would or could handle this.

The fundamental issue is that as soon as a string is put within a block comment it becomes plain text and just a sequence of characters. No matter what was proposed there'd be something which would break it.

For this case, the single quote, 'rest of line is a comment' character would work.

Phil Pilgrim (PhiPi)

No, there's no way around it. Trying to parse around assumed syntax inside a comment would be a prescription for disaster.

That may be one reason some languages use multi-character delimiters (e.g. /* and */) for block comments. It reduces the probability of finding them within commented-out strings. It also doesn't deplete the supply of syntactically-significant ASCII characters quite so rapidly. I can't help thinking that { and } might have come in handy for something more useful in the future.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

rokicki

Actually, there is a way around it. Well, sorta.

The {{ braces only match with }}. So for this specific case, you can use

{{a := string("ab}"}}

Of course now you have a meaningless documentation comment. But it's
still useful for commenting out blocks.

The {{ }} braces do not nest, however.

-tom