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

[Nick Sabalausky via Digitalmars-d-announce]

On 02/03/2016 12:25 PM, Dicebot wrote:
> On 02/03/2016 07:05 PM, Nick Sabalausky wrote:
>> Something that's been on my mind for a few months, finally got around to
>> a little write-up about it.
>>
>> We're Overlooking A Key Part of C/C++ to D User Migration:
>>
>> https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration
>
> For plain ABI interop it is actually something that should be doable by
> compiler as part of .di header generation - generate matching
> `extern(C)` wrappers for non-templated code (expanding all arrays to ptr
> + len pairs etc.).
>
> The problem is how you are going to expose templated stuff which
> dominates most useful D libraries.
>

I expect that in many, if not all cases, the library's FULL power and 
benefits might realistically only be accessible to D. But usually, some 
simple wrappers on the D side should be plenty to expose the primary 
use-cases to C. In particular, specially-selected pre-instantiations and 
simple convenience wrappers can go a long way.

For example, an XML library in D: This would likely be heavily templated 
to operate on ranges for everything. But usually, the lib's end users 
are only going to need UTF-8 strings, maybe UTF-16. The C users 
especially aren't likely to need more than that. So pre-instantiating 
for string and maybe wstring, wrapped up in non-templated wrappers would 
be perfectly sufficient to be useful to C users.

Or a regex lib: Compile-time regex (like ctRegex in phobos) would be out 
of the question, but the run-time version could still be exposed and 
useful. (Or, if the lib author *really* wanted to get clever and impress 
the C side, they could offer a simple CLI tool to pre-compile a regex 
outputting a D module and/or C header, which C programs could link in. 
But regardless, even just limiting C-land to the runtime version would 
still be offering something useful.)