On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:
> On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) 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.
>
> 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.

Wow, you converted DMC++'s front-end to D?

To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described isn't dead (it just revived a few weeks ago from a long slumber) and it should be possible to make a smaller codegen-less version for DMD that only depends on a few Clang and LLVM support libraries. Another possibility..

On 2/11/2018 5:43 PM, timotheecour wrote:
> It doesn't leave anything in Ddoc either, so that's not a viable workaround if that comment is intended to be a DDoc.

You're right that this will never be intrepreted as a Ddoc comment. But I infer that this resolves the non-Ddoc case?

As for Ddoc comments, your proposed syntax does not contain a trigger for Ddoc, and Ddoc already allows for multiple forms of escapes. It's hard to see where it would be useful for Ddoc - keep in mind that Ddoc has its own syntax and triggers.

On 2/11/2018 6:26 PM, Elie Morisse wrote:
> Wow, you converted DMC++'s front-end to D?

Yes, it's just frustrating for me to work on C++ code anymore. :-)

> To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described isn't dead (it just revived a few weeks ago from a long slumber) and it should be possible to make a smaller codegen-less version for DMD that only depends on a few Clang and LLVM support libraries. Another possibility..

Good ideas! Some things to consider:

1. I'd like this to be pluggable, so that different compilers can be used without being disruptive to dmd.

2. DMC++ is not only a C compiler, but a C++ compiler. The C++ compiler, though, is stuck on C++98 and is unlikely to see much improvement on that.

3. BetterC is called BetterC and not BetterC++ because D's C++ interop is more fragile than the C interop. I felt it better to nail the C end first.

4. It certainly would be nice to be able to insert C++ headers, too, but I'd expect more problems (!).

5. C is stuck at C99. Being a fixed target makes it more tractable. Supporting C++ means constant revisions and high support costs.

6. Using DMC++ as a front end would add somewhat less than a megabyte (half?) to the binary size of dmd. I have no idea what Calypso or other solutions would add. If they are large, they may only make sense as a separate executable as a filter.

On 02/11/2018 08:27 PM, Walter Bright wrote:
> 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.

Definitely all very cool stuff, no argument here. But for smaller things it would still be nice to hear something closer to:

"That's a reasonable point and a would be a nice touch, and it doesn't impact other things. Andrei and I, naturally, can't dedicate any of our resources to it because we have more crutial priorities on our plates, but we wouldn't necessarily veto a quality implementation."

instead of:

"It's not one of the big-picture items for D therefore it doesn't belong in D"

Though I do realize that's not likely to happen. It's not as if I'm saying "hey, go do this". All I'm really saying is "I like this idea, I'm in favor of it, and it's worth being open to." Not much more than that.

On 2/11/2018 8:59 PM, Nick Sabalausky (Abscissa) wrote:
> Though I do realize that's not likely to happen. It's not as if I'm saying "hey, go do this". All I'm really saying is "I like this idea, I'm in favor of it, and it's worth being open to." Not much more than that.

> "That's a reasonable point and a would be a nice touch, and it doesn't impact > other things. Andrei and I, naturally, can't dedicate any of our resources to > it because we have more crutial priorities on our plates, but we wouldn't
> necessarily veto a quality implementation."

It has nothing to do with my or Andrei's time, nor anything to do with whether it is a quality implementation or not.

We should not be adding features just because we can. They need a compelling case. This one does not have one. If such a case does emerge in the future, we can look at it again.

I do not wish to tacitly greenlight projects that have little chance of being incorporated. It isn't right to waste peoples' time like that. I don't derive any pleasure from being Dr. No, but somebody has to do it, and it falls to me.

On Monday, 12 February 2018 at 03:17:20 UTC, Walter Bright wrote:
> On 2/11/2018 6:26 PM, Elie Morisse wrote:
>> Wow, you converted DMC++'s front-end to D?
>
> Yes, it's just frustrating for me to work on C++ code anymore. :-)
>
>> To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described isn't dead (it just revived a few weeks ago from a long slumber) and it should be possible to make a smaller codegen-less version for DMD that only depends on a few Clang and LLVM support libraries. Another possibility..
>
> Good ideas! Some things to consider:
>
> 1. I'd like this to be pluggable, so that different compilers can be used without being disruptive to dmd.
>
> 2. DMC++ is not only a C compiler, but a C++ compiler. The C++ compiler, though, is stuck on C++98 and is unlikely to see much improvement on that.
>
> 3. BetterC is called BetterC and not BetterC++ because D's C++ interop is more fragile than the C interop. I felt it better to nail the C end first.
>
> 4. It certainly would be nice to be able to insert C++ headers, too, but I'd expect more problems (!).
>
> 5. C is stuck at C99. Being a fixed target makes it more tractable. Supporting C++ means constant revisions and high support costs.

C is currently at [C11]. Granted not many projects switched to it, as its changes were not as useful as C99. All the things added to C11 are features that try to extend the language in directions where it's better to switch to a better language like D (-betterC).
>
> 6. Using DMC++ as a front end would add somewhat less than a megabyte (half?) to the binary size of dmd. I have no idea what Calypso or other solutions would add. If they are large, they may only make sense as a separate executable as a filter.

[C11]: https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

On 2018-02-12 02:27, 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.
>
> 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.

Here you go [1]. It's a bit outdated now, from 2013, but it worked back then.

[1] https://github.com/jacob-carlborg/dmd/commit/2837d340c065cc2bf3f0a83cb96c4d9f22fb3a30

-- 
/Jacob Carlborg

On 2/12/2018 8:25 AM, Patrick Schluter wrote:
> C is currently at [C11].
> 
> [C11]: https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

Yes, you're right. I haven't paid any attention to C11 :/

The array bounds checking interface,

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm

is just sad. The one I proposed would actually work:

    https://digitalmars.com/articles/b44.html

On 2/12/2018 12:23 PM, Jacob Carlborg wrote:
> Here you go [1]. It's a bit outdated now, from 2013, but it worked back then.

The last dstep commit was November 2017.

> 
> [1] https://github.com/jacob-carlborg/dmd/commit/2837d340c065cc2bf3f0a83cb96c4d9f22fb3a30 

I take it dstep spawns the clang compiler?

On Monday, 12 February 2018 at 22:35:23 UTC, Walter Bright wrote:
> I take it dstep spawns the clang compiler?

It embeds the Clang frontend, which is designed to be usable as a library.

 — David