This fails to compile
void main()
{
/+
// /+
+/
}
giving this error
test.d(7): unterminated /+ +/ comment
test.d(7): found 'EOF' when expecting '}' following compound statement
It seems to be fine if it's not within a /+ +/ block, but once it is, the // comment is ignored, and since /+ is intended for commenting out code rather than just comments, this is not good behavior. All /+ and +/ should be ignored on lines where they are after //.
Comment #1 by bugzilla — 2010-11-16T16:53:36Z
Commenting out code should properly be done using:
version (none)
{
}
The only thing the /+ comments recognize are +/ and /+. They are working as designed. They are not intended to recognize tokens or other comments.
Comment #2 by issues.dlang — 2010-11-16T17:24:07Z
I could have sworn that the online docs said that one of the main reasons for /+ +/ was to comment out code, but regardless, it's not like you usually run into /+ or +/ inside of comments instead of delimiting them. I only ran into it because I was working on the D lexer for Phobos and one of the comments had them in it. The main issue is that they work as designed, so if this was as intended, then that's fine.
Comment #3 by nfxjfg — 2010-11-16T19:08:20Z
(In reply to comment #1)
> Commenting out code should properly be done using:
>
> version (none)
> {
> }
>
> The only thing the /+ comments recognize are +/ and /+. They are working as
> designed. They are not intended to recognize tokens or other comments.
That's unintuitive and error prone. Also you can't stick version anywhere. Obviously the design should be fixed.
Reopening as enhancement request.
Comment #4 by bearophile_hugs — 2010-11-16T19:46:48Z
(In reply to comment #3)
> (In reply to comment #1)
> > Commenting out code should properly be done using:
> >
> > version (none)
> > {
> > }
> >
> > The only thing the /+ comments recognize are +/ and /+. They are working as
> > designed. They are not intended to recognize tokens or other comments.
>
> That's unintuitive and error prone. Also you can't stick version anywhere.
> Obviously the design should be fixed.
>
> Reopening as enhancement request.
Be more gentle. The current behaviour is not obviously bad.
Comment #5 by bugzilla — 2010-11-17T01:08:25Z
>That's unintuitive and error prone.
I presume you mean the version(none). Unusual, yes. Unintuitive? How so? It's documented. Error prone? I don't see how - there's no way to set "none" as a version identifier.
>Also you can't stick version anywhere.
It's not necessary to stick it anywhere. It works fine for large blocks of code. For parts of an expression, /* */ works fine. It's hard to see an issue about this.
>Obviously the design should be fixed.
I don't think it's obvious wrong at all. It follows a simple rule, which I believe is better than having an arbitrarily complex rule with hard to remember special cases. Furthermore, if you do make a mistake with the /+ +/ nesting, you get an inevitable compiler error message.
And lastly, the current behavior has existed for 10 years and this is the first anyone has complained about it. Changing it would arbitrarily break existing code and hence annoy people for a rather dubious benefit.