Article: We're Overlooking A Key Part of C/C++ to D User Migration

[Nick Sabalausky via Digitalmars-d-announce]

On 02/03/2016 02:33 PM, H. S. Teoh via Digitalmars-d-announce wrote:
> On Wed, Feb 03, 2016 at 07:25:55PM +0200, Dicebot via Digitalmars-d-announce wrote:
>>
>> The problem is how you are going to expose templated stuff which
>> dominates most useful D libraries.
>
> This is certainly an interesting idea worth exploring, and certainly
> doable for plain ABI interop, as Dicebot says.
>
> For templates... I dunno, some stuff is probably untranslatable, or at
> least, can't be translated into a form that's suitable for end-users,
> like alias parameters, variadics, tuple/AliasSeq shenanigans, etc.. But
> some of the simpler stuff might be doable.
>
> Perhaps... this is a crazy idea that just occurred to me -- write a D to
> C++ template syntax translator?

Well, I don't think it's worth (at least short term anyway) getting too 
caught up in the idea of more advanced stuff like that, and equivalent 
template semantics and such, being usable from the C/C++ side of an 
interface.

Much of the time, the bulk of a lib's use-cases can be exposed via 
simple wrappers that expose a simplified API. Naturally, this wouldn't 
be as nice as benefiting from D's full feature set, but if you're not 
writing *in* D then you're kind of forgoing a lot of those niceties anyway.

Longer term, maybe more tricks could be devised to offer more benefits 
to a D lib's C/C++ users. Or maybe not. But either way, that's not 
really the important part. The important part is just straightforward 
out-of-the-box access to a D lib's main use-cases, rather than 
reproducing as much of the D experience as possible.

Perhaps I was overstating a bit saying "every" D library. Naturally, 
some libs will make more or less sense to use from C/C++ than others. 
But with just a little thought given to "What is this lib's MAIN 
purpose? What are the IMPORTANT features that could be wrapped up in a 
simpler C-accessible API, verses merely D niceties that aren't necessary 
for C/C++ users to gain usefulness from this lib?" With just a little 
thought given to that, I think we could offer some actual usefulness to 
C/C++ users, which simultaneously benefits them and helps our street cred.

Of course I'm not saying D libs should jettison D niceties for the sake 
of C/C++ compatibility. But just offer whatever C/C++-sensible subset 
they reasonably can to the C/C++ world.

 From the C/C++ perspective, think of it like exposing a C/C++ library 
with "the core of this is written in D" as an implementation detail. Of 
course, actual D programs would get even MORE benefit from the lib, by 
bypassing the "funneling this into C/C++-compatible form" layer.