On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote:
On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
>
> The difference is they would have to rework their existing
> code. If you are writing D source code bindings for your
> code, then you are essentially writing new code. You don't
> have to worry about backwards compatibility.
Why would you write bindings if the computer can do it for
you, better, faster and consistently?
Faster and consistently, sure. But I don't think 'better' is
possible.
From my experience, in many cases, C++ really doesn't express
well in
D by direct translation. I tend to do significant massaging of
the C++
helper material to improve the experience from D.
Usually C++ libs have a lot of helper material in the form of
macros,
little template utilities, inline wrappers, and they can almost
always
be expressed more nicely in D with some tweaking.
I often also insert some additional inline D helpers/wrappers
nearby
the externs, which help adapt the signatures; ie, apply some
attributes, or make a slice-based API that transforms to
ptr+len args,
maybe implement a range helper, that sort of thing.
The goal is to make the API attractive such that a user is
compelled
to prefer interacting with the lib from D than from C++.
C++ namespaces interfere with overload resolution in
particular, and
that makes this goal harder.
It probably depends on your use. If you're just calling a C++
lib, and
wrap it up in a box for use in your local code, a machine
translation
for the API might be fine. I'd call that 'making use of a
feature
lib'.
If you are linking to a lib that is a fundamental part of your
application infrastructure, you absolutely must do significant
manual
work to make the C++ code express nicely to D, otherwise the
user-experience interacting with the C++ api from D will be
worse than
just using C++.
If the C++ experience is better than from D, then D experience
ceases
to exist as no case can be made to prefer D over C++, the
project is
moot, and I have wasted my time.
The D experience must not just be equal to the C++ experience,
it must
typically be substantially better in a variety of ways, and I
have
never been able to have such an experience interacting with C++
without making some manual effort towards quality bindings.
The current namespace mechanics put SOOO much more strain on
that goal
than is necessary.
One other important feature of quality bindings, is that the
binding
itself must be readable and maintainable. The binding itself is
the
very first showcase to C++ programmers of how their API's could
be
better in D. It must be well organised (like normal D code),
and the
current situation with boilerplate invading the works is
destructive
toward that end.
Of course, thanks to this namespace situation, when involving
with
these hideous workarounds, they are usually objectively NOT
better in
D, and C++ programmers do indeed recognise that immediately.
Would it be inaccurate to make a distinction between bindings and
wrappers ? It's always going to be less pleasant to call even C
bindings from D then an idiomatic D wrapper written on top.
But if you have automatically generated bindings then you can put
the effort into the wrappers and it's easier to do the latter
incrementally.
And being able to use a library at all even if slightly
unpleasantly without having to pay a big price up front beats
having no choice. At least for us the sequencing of cost matters
more than the total cost, and the calendar time element of cost
to being able to write a passable and useful first version is
more important than the pecuniary element.
We have many more people who are not C++ programmers but express
their ideas in D then we do people who know C++ pretty well.
BTW I almost think the D Foundation should organise a library
wrapping as a service marketplace ;). Lots of people in the
community are open to remote work part or full time. But the
cost is in finding the right people and also to some extent
supervising and organising the design and work. That could be
just another forum in the beginning.