On Saturday, 4 August 2018 at 09:43:13 UTC, Dukc wrote:
> On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote:
>>
>> Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please?
>
> Why?

The C standard library not a true and intrinsic dependency of D, and is outside of D's charter.  There are druntime implementations that leverage the C standard library, but I believe that was largely done for expediency.  If one wants to leverage the C standard library for a certain druntime implementation, that's fine, but it should be privately imported.

D is a much more capable programming language than C, and whatever functionality is being imported from the C standard library can be better implemented in D with compile-time optimizations via templates, memory safety, and other benefits.

Mike

On Monday, 6 August 2018 at 02:17:28 UTC, Mike Franklin wrote:
> The C standard library not a true and intrinsic dependency of D, and is outside of D's charter.  [...]
>
> D is a much more capable programming language than C, and whatever functionality is being imported from the C standard library can be better implemented in D with compile-time optimizations via templates, memory safety, and other benefits.

So if I understood correctly, you did not mean ejecting core.stdc but that DRuntime should not depend on it? Yeah, that sound reasonable for me too (If it is practical effort), regardless of DPP. But C libraries should be kept as a backup for platforms where there aren't D implementations. For example, IO functions could first try (using design by introspection) some implementation like https://github.com/schveiguy/iopipe. And if that does not support the enviroment, then fallback to C IO.

On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote:

> One benefit of D is as a better glue language that integrates well with other languages and ecosystems.  Many people who know a bit about D have no idea that interop can work so easily or well.
>
> So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for:
>
> Python (via autowrap:python and pyd)
> C (via dpp)
> C++ (extern(C++) for now)
> R (via embedr)
> Julia (via C interface, including julia.h via dpp)
> Lua (if LuaD stable enough)

And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab

On Monday, 6 August 2018 at 13:32:23 UTC, bachmeier wrote:
> On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote:
>
>> One benefit of D is as a better glue language that integrates well with other languages and ecosystems.  Many people who know a bit about D have no idea that interop can work so easily or well.
>>
>> So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for:
>>
>> Python (via autowrap:python and pyd)
>> C (via dpp)
>> C++ (extern(C++) for now)
>> R (via embedr)
>> Julia (via C interface, including julia.h via dpp)
>> Lua (if LuaD stable enough)
>
> And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab

If an Octave extension written in D works, do you have anywhere to point me to on what's needed to make it work with Matlab?  (Is it usually drop-in compatible?)

On Monday, 6 August 2018 at 13:43:46 UTC, Laeeth Isharc wrote:

>> And Octave (via the .mex interface) - this one's important because it opens the door to using D as an extension language to Matlab
>
> If an Octave extension written in D works, do you have anywhere to point me to on what's needed to make it work with Matlab?  (Is it usually drop-in compatible?)

Unfortunately I don't use Matlab and don't have a license to try out. However, as I understand Octave's mex interface, the original goal was to allow Matlab extensions to be compiled and run in Octave. Otherwise you could have a core language that ran Matlab code but extensions would still lock you in to Matlab. Thus, I'm assuming that the ability to use Octave's mex interface implies ability to use Matlab's.