On 7/7/12, Walter Bright <newshou...@digitalmars.com> wrote: > so you could do things like: > > import "stdio.h"; > > and the D compile would fork/exec Dstep, generate the corresponding .d file, > and > import the .d file.
Personally I think this is heading in the wrong direction. A D user shouldn't have to deal with C syntax or peculiarities of wrapper libraries, the experience of using a wrapper library should be as transparent as possible. Such a wrapper library should look just like any other D library to the user. Wrapper maintainers can use tools to generate bindings, and the users might have their own tools such as a package manager to make discovery & installation of those libraries easy. There's compile-time performance issues to consider. Sure, you could cache the results of generating a library, but this is still a penalty because every user will have to wait for that import statement to finish the first time and cache the results before they can use the library, as opposed to the traditional way of downloading a maintained wrapper library which you don't have to re-wrap but just need to compile. I don't mean to sound discouraging, and this all might work for simple C libraries and Dstep, but there's a penalty for introducing special syntax and semantics into D for something that can be and is usually done externally by wrapper maintainers (think how we're always trying to move things away from the D language and replace it with more flexible and more easily debuggable library features). Maybe this feature would look great in a D vs Go comparison table, but I don't see the benefit of such a magical feature. I'd rather we have a package manager instead, which incidentally again Jacob is working on. Incidentally I'm also working on my own wrapper generator, although this one handles C and C++. But it won't be done soon (it's close though).