On Monday, 9 June 2014 at 19:14:15 UTC, Jacob Carlborg wrote:
> Adam, I noticed that you mentioned DStep in the book. By reading the part about integrating with C++ I got the impression that DStep can handle C++. Currently, that's not the case.

blargh, I thought it could do more. Does it at least work to pull out extern "C" functions from a C++ header?

On Tuesday, 10 June 2014 at 17:31:52 UTC, Lars T. Kyllingstad wrote:
> Like the fact that you can @disable this() for a struct, even though you can't implement it.

If my memory is working properly I actually think I was the one who suggested that to Walter a few years ago when it was introduced, though odds are I stole the idea from somebody else first and my memory is just a bit selectively egotistical :P

But I think @disable is a really cool thing for so many reasons. The two first ideas I had with it was the not null and ranged integer structs. Then the move semantics can come from it too. So can selectively disabling other operator overloads; forwarding most things to a member but filtering out some operations.

Disabling default construction still has a few compiler bugs so it isn't watertight but I've found it is really nice to have.

On 10/06/14 19:43, Adam D. Ruppe wrote:

> blargh, I thought it could do more. Does it at least work to pull out
> extern "C" functions from a C++ header?

Hmm, I haven't tried that. You need to specified which language to use. Currently DStep has hard coded its language support, in which C++ is not included.

It starts to get more complicate if it needs to support multiple languages in the same file. It should be possible, but then I think every declaration will need to be prefixed with "extern (C)".

-- 
/Jacob Carlborg