proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa)]

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.