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.

Reply via email to