On Mon, 29 Jun 2015 22:30:50 -0400, Walter Bright
<[email protected]> wrote:
On 6/29/2015 8:30 AM, bitwise wrote:
FWIW, I've thought through most of my use cases, and it seems I can do
without
this feature(both mine and Daniels suggestions). This is mainly because
I've
decided to write anything close to the system in C++. If/When the day
comes that
system APIs are written in D, this may change, but I don't see this
happening in
the foreseeable future. IMO, the D community's time would be better
spent
improving D/C++ interop than trying to make D a systems language. At a
glance, I
don't see a binding for OpenCV or FBX SDK, and although there are many
bindings
for OpenGL and such, I wouldn't feel safe relying on them to be up to
date or
complete. The lesser evil clearly seems to be writing some C++.
I don't believe a macro processor is necessary to write systems code,
nor do I believe version expressions are, either.
Was pretty sure I worded that wrong.
I'm willing to concede at this point that if I was writing some fresh new
systems code, I could deal with the limitations of 'version', and that it
does seem like good practice not to spam preprocessors/version everywhere,
but for me, a big selling point of D is _not_ having to
re-write/refactor/re-think my code.
From the point I picked up D, and having a strong background in C++, it
just felt natural, and I was able to start programming with it
immediately. I've been able to transfer over a lot of design-patterns/code
with little to no effort.
Still though, I think that with the dominance of C++ for system APIs, it
makes more sense right now to keep the interop layer as narrow as
possible, and just access the system from C++. I can then create a small
group of interfaces for accessing graphics/audio/etc..
So I guess this nullifies my original grievance. Sorry for nagging :)
Bit
