On Friday, 9 February 2018 at 08:54:09 UTC, Timothee Cour wrote:
> * `/* */` should never be used
Not a single reason for that

> * properly nested `/+ +/` indeed don't cause issues
Disproved two times in this thread. Anyway nothing properly done causes issues.

> * unrestricted code (eg foreign code or unfinished D code commented
> out) also cause issues
Superficial

On Friday, 9 February 2018 at 08:57:49 UTC, Timothee Cour wrote:
> version(none) { FOO } doesn't work if FOO doesn't parse.

version(none)q"EOS
  FOO
EOS";

On 02/09/2018 03:52 AM, Kagamin wrote:
> On Friday, 9 February 2018 at 08:44:31 UTC, Nick Sabalausky (Abscissa) wrote:
>> On 02/09/2018 03:42 AM, Kagamin wrote:
>>>
>>> Nested comments are superficial though,
>>
>> Not if you've ever commented out a block of code.
> 
> Comment this:

'kay:

// string sedArg="s/ +/ /";

Don't see how that's remotely as common as "*/" in a C-style-comments codebase or commenting out something at the sub-statement level, like a function argument, type modifier or sub-expression, but hey, I guess if you have instances of that all over most functions in your codebase, then, yea, I guess disabling code with /+ +/ would be pretty nasty.

> 
> Comments don't respect even lexical structure of commented code that you expect, version(none) does.

Uhh, you do know that IS nesting, right? And that it fails in far more cases than /+ +/ does? And is far less widely supported by editors? And that it DOES nest? And also that it nests?

On 02/09/2018 04:23 AM, Kagamin wrote:
> On Friday, 9 February 2018 at 08:57:49 UTC, Timothee Cour wrote:
>> version(none) { FOO } doesn't work if FOO doesn't parse.
> 
> version(none)q"EOS
>    FOO
> EOS";

Huh? So are you *pro-* or *anti-* heredoc?

But ok, that works, unless the code contains `EOS"`. Better change it to:

version(none)q"hey-hey-hey_dudes_I-bet-NOTHINGinMYcode-is-gonna-useTHIS
   FOO
hey-hey-hey_dudes_I-bet-NOTHINGinMYcode-is-gonna-useTHIS";

At least until I go quoting this post in my code. Crap. Guess then I could go back to:

version(none)q"EOS
   FOO
EOS";

Or, y'know, just cut out all the noise and just do:

/+
  FOO
+/

and be done with it.

On 02/09/2018 04:09 AM, Kagamin wrote:
> On Friday, 9 February 2018 at 08:54:09 UTC, Timothee Cour wrote:
>> * `/* */` should never be used
> Not a single reason for that
Except of course for the ones that have been pointed out. And for the reasons you yourself brought up in favor of version(none). Not a single reason aside from all of those.

>> * properly nested `/+ +/` indeed don't cause issues
> Disproved two times in this thread. Anyway nothing properly done causes issues.

Being that the issues with /* */ are a superset of the issues with /+ +/, they clearly cause fewer issues than /* */.

>> * unrestricted code (eg foreign code or unfinished D code commented
>> out) also cause issues
> Superficial
Irrational

On Friday, 9 February 2018 at 09:34:01 UTC, Nick Sabalausky (Abscissa) wrote:
> Don't see how that's remotely as common as "*/" in a C-style-comments codebase or commenting out something at the sub-statement level, like a function argument, type modifier or sub-expression, but hey, I guess if you have instances of that all over most functions in your codebase, then, yea, I guess disabling code with /+ +/ would be pretty nasty.

I have a few subexpression comments due to language bugs, so function signatures are temporarily changed, it's just version(none) never failed for me.

>> Comments don't respect even lexical structure of commented code that you expect, version(none) does.
>
> Uhh, you do know that IS nesting, right?

It's not a comment though, it disables code on semantic level way above raw character stream level, that's why it works better, also it's often one liner.

> And is far less widely supported by editors?

If you want it be bound to a shortcut, many text editors support invocation of external tools or text snippet expansion.

On Friday, February 09, 2018 08:42:08 Kagamin via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 07:04:26 UTC, Nick Sabalausky
>
> (Abscissa) wrote:
> > (If I were in change of the world, /** and /* both would be compiler errors, banned from all commits, and non-nesting block comments of all types would be prohibited from all langauges upon pain of...well, pain. They are spawn of satan and should never exist.)
>
> Nested comments are superficial though, they were a mistake, really.

Seriously? Nested comments are _awesome_. IMHO, if anything, the fact that
the language has /* */ and /** */ is what's terrible. It makes sense for
porting code, but in all respects, they are worse than /+ +/ and /++ +/. I
hate it when I'm working in languages other than D and am forced to use
/* */ and deal with the fact that they don't nest. It may be a small thing,
but the fact that D has nested comments is just one more thing on the list
of things that add up to make D a lot more pleasant to work with than other
languages.

- Jonathan M Davis

On Friday, 9 February 2018 at 09:42:46 UTC, Nick Sabalausky (Abscissa) wrote:
> Huh? So are you *pro-* or *anti-* heredoc?
I personally prefer python's triple quoted strings. Elegant, simple and enough for most stuff. That example only shows what D has.
version(none)q{ FOO }; is likely to work for most stuff too.

> But ok, that works, unless the code contains `EOS"`.
The very fact that I invented that just for this thread is evidence that it's not a rampant issue.

On 02/09/2018 04:48 AM, Kagamin wrote:
> On Friday, 9 February 2018 at 09:34:01 UTC, Nick Sabalausky (Abscissa) wrote:
>>> Comments don't respect even lexical structure of commented code that you expect, version(none) does.
>>
>> Uhh, you do know that IS nesting, right?
> 
> It's not a comment though, it disables code on semantic level way above raw character stream level, that's why it works better, also it's often one liner.
> 

You seem to keep going back and forth on whether you like nesting or consider it a mistake. Hard to keep up.

>> And is far less widely supported by editors?
> 
> If you want it be bound to a shortcut, many text editors support invocation of external tools or text snippet expansion.

I meant syntax highlighting. I've given up on binding the comment/uncomment mechanism I want to key shortcuts: Dealt with too many editors that have too much trouble with something that should be so simple, wheras just plain typing works in nearly any editor. Which is all the more reason I don't use version(none) to disable code.

On 02/09/2018 05:31 AM, Kagamin wrote:
> On Friday, 9 February 2018 at 09:42:46 UTC, Nick Sabalausky (Abscissa) wrote:
>> Huh? So are you *pro-* or *anti-* heredoc?
> I personally prefer python's triple quoted strings. Elegant, simple and enough for most stuff. That example only shows what D has.
> version(none)q{ FOO }; is likely to work for most stuff too.

/+ +/ is likely to work for most stuff, too.

I think version(none) has solidly proven that higher-level semantic code-disabling, while sounds like a great idea on paper, actually provides no practical, non-theoretical gains other than the ability to nest, which /+ +/ shares (along with the ability to be used in more scenarios and be less verbose). In real-world use, the only thing all that "smart" lexical processing done by version(none) accomplishes is to *create* new scenarios where the compiler says "Nope, disabling that code like that doesn't work for me. Try again."

>> But ok, that works, unless the code contains `EOS"`.
> The very fact that I invented that just for this thread is evidence that it's not a rampant issue.

Ditto to code containing +/

As for the OP however, the question isn't how frequent, but what can be done when it does occur. All of our trouble scenarios with disabling blocks of code can be dealt with fairly cleanly and easily (although moreso with /+ +/ than version(none) IMO). But the doccomment scenarios brought up aren't so simple to deal with:

/**
Be sure to check the various files at extras/foo*/package.d
and also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/

Unlike the "disabling code that contains the end-of-disabled-code token" stuff, THIS example isn't quite so trivial to deal with in a way that's reasonably readable from both the generated docs and from within the code itself.