extern(C) with function returning user type

[Laeeth Isharc via Digitalmars-d-learn]

On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
> On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
>> On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
>>> So idk, it feels silly and counterproductive to have D not 
>>> able to natively use C libraries. Are we just gonna have to 
>>> write D bindings to every notable library out there? Also I 
>>> don't see how it'd be problematic, if you don't want a C 
>>> preprocessor kicking in, then just don't import any C source, 
>>> and then the compiler will just skip that step.  :P
>>
>> That's how you end up with C++. The solution there is to use 
>> only a subset of the language, but since everyone has her own 
>> subset, you can either learn the whole language or not 
>> interact with anyone else's code. A tool-based solution is 
>> much better.
>
> It's a fair argument. Regardless though, I feel like D has lost 
> it practicality for me for the time being. I might come back to 
> it in half a year and see if anything changes, but 
> unfortunately I don't see myself using D for any of my projects 
> I got lined up.

You have to make the right decision for you.

But from what you say, I am not sure if you are making it on the 
basis of proper information about the tradeoffs involved.  It 
shouldn't be a difficult thing to port the headers for most C 
libraries.  Use dstep to do the work, and a bit of tidying up 
after (which gets easier each time).  Less time involved than 
that involved in trying to fix just one nasty memory leak or 
pointer problem in C code.

Sometimes though, cashflow dominates return on investment.  If 
one cannot spare the time then, ROI on learning something new is 
irrelevant.  One can't do much about that in the short term.