Solar wrote:
I always felt the biggest advantage of them being that they nicely define the "public interface" of your code, without the actual implementation getting in the way.
Luckily, the language developer agrees, so you can have both if you need it.
Here is the description. Basically, you have have these D Interface files that act much like header files would. Yet, they are generated by the compiler from the source, so you don't need to maintain them separately. It is a compiler feature, so it may not be in all compiler implementations.
neonek wrote:
And what are that bugs in compiler ?
There are some issues with the templating, but they aren't a big deal. I forget exactly, but it doesn't like to iterate through a list of strings at compile time or something. You can make it a tuple instead, and its just an extra operation. (ran into this in /src/user/syscall.d)
D has an import syntax for including code modules. It breaks when you have circular imports with a depth of 2 or more. There is an annoying workaround. (ran into this EVERYWHERE)
And the errors that it reports are complete nonsense at times. (it's all in good fun)
neonek wrote:
Maybe, Wilkie you'll add some info about basic setup in D to wiki ?
Certainly seems possible. I did not have much involvement with that aspect, but I'll ask around. We have been pushing documentation as of lately, and one of the visions of the project is to provide an academic outlet, and thus provide as much information about the particulars of implementation. This is definitely one facet of the development we had forgot to document. I'll throw it on the task queue