On 2/10/2018 7:27 PM, Jonathan M Davis wrote:
> And it's already kind of silly
> that we have as many comment types as we do.

Even more comment types implies we don't know what we're doing :-(

On Sunday, 11 February 2018 at 01:01:21 UTC, Jonathan M Davis wrote:
> You could also always just declare a DDOC macro.
>
> Just put
>
> Macros:
>     PLUS=+
>
> in the ddoc comment and then use $(PLUS) instead of +. It's more verbose that way given that PLUS isn't one of the standard ddoc macros, but it's more idiomatic to look at.

This won't work because URL linkification happens before macro resolution, so $(PLUS) will break URLs. But you can of course always use $(HTTP ...) or equivalent to emit a link explicitly.

On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
> /"EOC
> This is a multi-line
> heredoc comment allowing
> /+ documented unittests containing nesting comments +/
> and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
> EOS"/

This syntax is syntactically ambiguous.

struct StringNumber
{
    string s;
    string opBinary(string op)(string b)
    {
        import std.conv;
        return mixin(`(this.s.to!long ` ~
            op ~ ` b.to!long).to!string`);
    }
}

unittest
{
    assert(StringNumber("4")+"2" == "6");
    assert(StringNumber("4")-"2" == "2");
    assert(StringNumber("4")*"2" == "8");
    assert(StringNumber("4")/"2" == "2"); // Conflict!
            // Division by string, or nested comment?
}

On 02/11/2018 09:32 AM, Vladimir Panteleev wrote:
> This syntax is syntactically ambiguous.
[...]
>      assert(StringNumber("4")/"2" == "2"); // Conflict!
>              // Division by string, or nested comment?

Strictly, it's not worse than `/*`, is it?

----
assert(4/*(new int(2)) == 2);
    // Division by dereferenced pointer or comment?
----

I.e., it's a comment and you have to add a space to make it division.
But `/"` would break existing code, of course.

On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote:
> same exact idea as motivation for delimited strings (https://dlang.org/spec/lex.html#delimited_strings)
>
> ```
>
> auto heredoc = q"EOS
> This is a multi-line
> heredoc string
> EOS"
> ;
>
> /"EOC
> This is a multi-line
> heredoc comment allowing
> /+ documented unittests containing nesting comments +/
> and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
> EOS"/
>
> ```
I thought about it,  what if you define, that the /+  +/ comment, is not started by
'/+'  alone but by '/+ ' that means that the char behind the plus defines the ending of the comment.
So that /+my_special_block  has to end with  my_special_block+/
And '/+ '  with ' +/' where all whitespace characters should be allowed (\newline \tab \space).

I know that this might be a somehow breaking change, but it would not require a totally different kind of syntax.
And the mentioned URL-Strings lib++/  will not match for '/+ ' .
Would be interesting how often people write /+directly followed by the comment, without a space or the same at the end+/

On 02/10/2018 06:03 PM, Walter Bright wrote:
> 
> There isn't any commenting scheme that won't trip you up with certain characters 

That's exactly the whole point of heredocs ever existing in the first place, its exactly the problem they're created for.

> in the comments. I don't see a compelling case for adding another kind of comment.
>

That's the same exact reason most languages don't have most of the nice things in D, like separators for numeric literals: Because they're not strictly necessary. But if D had never been willing to improve the state of the art by not being afraid of "not stricktly necessary" features, very few of us would have ever had reson to come onboard with D in the first place. And yes, I know D's not at that point any more. And that's one of my biggest dissapointments with D.

> Vladimir's suggestion to use %2B instead of + seems to resolve this adequately.

Only for URLs. "URLs" was just one example of a language that can leas to trouble.

On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
> That's the same exact reason most languages don't have most of the nice things in D, like separators for numeric literals: Because they're not strictly necessary. But if D had never been willing to improve the state of the art by not being afraid of "not stricktly necessary" features, very few of us would have ever had reson to come onboard with D in the first place. And yes, I know D's not at that point any more. And that's one of my biggest dissapointments with D.

D is already a very large language. There's got to be a point where some pruning makes for a better language. Adding more and more lightweight features for 0.1% use cases when we neglect heavyweight features for 30% use cases is not where we should be shooting our arrows.

Know what is a heavyweight problem worth our while? Having dmd be able to directly read C .h files, so the poor user does not have to manually translate them.

We've already got a huge chunk of that problem solved. The Digital Mars C/C++ front end is now Boost licensed. It can be used. It's already been converted to D! The preprocessor in it is a bit dated and a bit too specific to Windows - but we've got Warp now!

Replace the preprocessor in dmc++ with Warp, slice off the back end, and make it a module that dmd can import.

Wouldn't it be nice to support:

    import stdio.h;    // Look, Ma! C headers!

There are some intractable issues, and it may be impossible to get 100% to "it just works", but looking past that it might be a huge win for us.

And, let's not forget working on ref counting.

On 2/8/2018 7:06 PM, Timothee Cour wrote:
> /"EOC
> This is a multi-line
> heredoc comment allowing
> /+ documented unittests containing nesting comments +/
> and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
> EOS"/

Easy:

    mixin template comment(string s) { }

    mixin comment!q"EOS
    This is a multi-line
    heredoc comment allowing
    /+ documented unittests containing nesting comments +/
    and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
    EOS";

It doesn't leave anything in the object file, either.

On Monday, 12 February 2018 at 01:39:31 UTC, Walter Bright wrote:
> Easy:
>
>     mixin template comment(string s) { }
>
>     mixin comment!q"EOS
>     This is a multi-line
>     heredoc comment allowing
>     /+ documented unittests containing nesting comments +/
>     and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
>     EOS";
>
> It doesn't leave anything in the object file, either.

It doesn't leave anything in Ddoc either, so that's not a viable workaround if that comment is intended to be a DDoc.

On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:
> Know what is a heavyweight problem worth our while? Having dmd be able to directly read C .h files, so the poor user does not have to manually translate them.

read directly C++ header files instead of C .h files is what we should aim for. https://github.com/Syniurge/Calypso/ is actually already doing just that and already works in many situations (eg opencv).

> Replace the preprocessor in dmc++ with Warp, slice off the back end, and make it a module that dmd can import.
>
> Wouldn't it be nice to support:
>
>     import stdio.h;    // Look, Ma! C headers!
>
> There are some intractable issues, and it may be impossible to get 100% to "it just works", but looking past that it might be a huge win for us.

llvm+clang is a much better approach, guaranteeing compatibility with not just C but also and especially C++ (including current and future C++ standards). Calypso already understands C++ templates, C++ exceptions, can return C++ classes by value (not just by reference), without the restrictions imposed on extern(C++) classes/structs.

```
modmap (C++) "opencv2.hpp";
import (C++) cv.Mat;
// can now use C++ templates, functions, macros etc in D code.
```

There are of course a number of issues left to be ironed out, but it's a much more promising direction than restricting ourselves to C (as done with `cgo` for go). That's where we should focus our efforts as far as interop is concerned.