Adding Markdown to Ddoc

[Chris]

On Tuesday, 12 December 2017 at 13:50:42 UTC, Bastiaan Veelo 
wrote:
> On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
>> On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis 
>> wrote:
>>>
>>> And then you have to worry about something like int* screwing 
>>> with things, because the compiler decides that you wanted 
>>> italics. Honestly, I don't think that something like $(I foo) 
>>> is very onerous - it's not all that different from <i>foo</i> 
>>> or [i]foo[/i] (which plenty of folks are familiar with), but 
>>> it's shorter and less visually noisy - and it doesn't risk 
>>> having stuff that isn't supposed to be markdown being treated 
>>> as markdown.
>>>
>>> [...]
>>
>> Try this one (paste it into 
>> http://spec.commonmark.org/dingus/):
>>
>> # CommonMark
>>
>> ```
>>     int* ptr;
>> ```
>> `int*` is a pointer to an integer.
>>
>> int* is a pointer to an integer.
>
> Coming up with a counter example is easy. Try this:
>
>> To dereference a pointer variable, write *i. To define a 
>> pointer variable, write int* i.
>
> Inserting backticks obviously solves this and personally I 
> would be fine with that requirement, but Markdown is not 
> completely harmless. The above line comes out totally as not 
> intended.

Like with regex, you can always escape characters with special 
meanings:

To dereference a pointer variable, write \*i. To define a pointer 
variable, write int* i

However, as you said, code would be between back ticks anyway, 
and even $(I int) can be messed up, if you're not careful with 
brackets and spaces etc. - which is true of _any_ markup 
language. By saying "the compiler decides" to do something that 
wasn't intended after the programmer has not been careful with 
the syntax, you can dismiss _any_ syntax, including D's.

Also, to dismiss CommonMark on the grounds that it is not 
standardized yet (officially) while millions of programmers are 
familiar with it an use it on GitHub doesn't make much sense, 
especially while Ddoc is nowhere near CommonMark in terms of 
usage, familiarity, ease of use and popularity.