On 6/4/17 01:18, Jakub Szewczyk wrote:
My interest is less in code ports than bindings to the actual code. My
experience with code ports or translations is that often subtle bugs
creep in during translation due to the fact that each language has
This is an interface to the Mono libraries, D/CLI would require quite a
lot of compiler changes, both on the front-end and back-end side, but
thanks to metaprogramming a wrapper library can get very close to such
I plan on making an automated D to Mono bridge, akin to LuaD, so that it
can be used as a scripting platform for e.g. games. I haven't thought
about doing it the other way around, but now it seems like a very
interesting idea! Unfortunately no XAML
(http://www.mono-project.com/docs/gui/wpf/), but many other libraries,
such as XWT (https://github.com/mono/xwt) could be ported this way, I'll
certainly look into it.
What I am thinking about is a tool that loads an assembly, examines it's
types and methods via this API and emits D code that directly interfaces
into the .NET types via this API. The tricky part here is mapping the
.NET dependencies into D. The moment the library exposes a type from a
dependency, that dependency ALSO needs to be included somehow. All
libraries reference "mscorlib", AKA the BCL, so we'd have to provide a
"mono-bcl" package on DUB.
One solution is to simply include the exposed dependency in the
generated code. This would work because while the D code would have
distinct types for the same class, the underlying .NET types is the
same. The drawback with this approach is that you can't share the
instances across D interfaces as the types are different. For example,
Library1.B and Library2.C both rely on Dependency.A. In D you would have
Library1.B.A and Library2.C.A and these two types, while the same in
practice, are different types to the compiler. Maybe a clever use of
alias can solve this at code-gen time... more research is required there.
The other solution is too have the code-gen throw an error when it
encounters a type from a dependency. This ensures that the types are the
same across libraries in D, but at the cost of increased complexity for
the developer when running the tool (specifying extra deps) and when
building their code (ensuring all relevant packages are built/referenced).
I'm not sold on either one. And it'd be best if it's possible to support
As for the WPF remark, my brain immediately jump to trying to interface
to .NET/Core using a similar mechanism, but alas some research time
indicates that this is not possible outside of COM. *le sigh* My
apologize for the random side-track.
On the GC side I was mostly thinking about GC Handles so that the
objects don't get collected out from underneath us. That is something is
trivial to code-gen.
Mono actually supports some kind of GC bridging as far as I understand,
as there is a sgen-bridge.h header just for that, and it has apparently
been used in the C#-Java Xamarin interace on Android. As for exceptions
- D functions have to be wrapped in a nothrow wrapper, but that can be
completely automated with templates. The other way around is also quite
simple - when invoking a Mono function a pointer can be given that will
set an exception reference if one is thrown from the .NET side, and a
wrapper can easily rethrow it back to D.
As for exceptions, I like the catch->translate->rethrow mechanism. And
if the exception is unknown we could simply throw a generic exception.
The important thing is to get close to the D experience, not try to map
I can make a static library version, it's just some regex substitutions
done on the functions file actually, most probably I'll publish it
today. It will be a dub subconfiguration like it is the case for GLFW3.
Btw, I've manually ported the basic and configuration headers, so that
no mistakes are made, and then used DStep and a modified DStep to
generate the rest of the headers - my modification was only to change
the way function declarations are generated, to make them in derelict
form of alias da_function = void function(...);, and the rest was done
with quite a lot of editor(VSCode) shortcuts.
Thank you for this! I find static libraries easier to deal with. I'm
sure other people have differing opinions, so having both would make
I am very excited about this!