First of all thanks for this fast answer! > On 1/19/2012 12:48 PM, Roberto Caravani wrote: > > I think this would be a real neat and very important feature, when it > > comes to shared libraries. Is there any plan to implement something > > like that in the future? Do I miss something? > > The pimpl pros and cons are the same for C++ and D.
Well, yes they are currently. But as D has pure reference semantics for classes, it would be easier to handle the case when the size of an object is not known at compile time. It basically comes down to having operator new read the size from the library and having derived classes members do some offset calculation. (Member initialization would have to be done by a function) Is there something missing? Is there a flaw in my proposal? Isn't it worth the effort? What are the problems? In Java pimpl for ABI compatibility seems not to be neccessary, according to: http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html (It states that you can freely add and remove private fields) but ok, Java is not a system programming language, they might cheat somehow. Such a feature seems really cool to me, especially for library developers, because they have to care less that they are implementing a dynamic library. And you can easily avoid the costs if you don't need it, no rewrite necessary, just a recompilation of the program. (Not even the library, if you don't care about the hidden static size member and the initialization methods) Maybe I am completely wrong, but if so I want to know This is not really a feature request, as there are far more important things to do at the moment. This is more a: "Is it possible?" "Would you like to have it, if someone else implemented it?" Best regards, Robert P.S.: Another benefit I forgot to mention: For such a not exposing .di file, I think you can even remove all non public imports (if there are no inline methods), as all you need to know is the size of the object. I know that compilation time isn't that much of an issue as with C++, but during development you could use such non exposing .di files, which would change much less often. Thus recompilation of object files due to changes in the di files could be decreased, shortening compile time for large projects. In addition the compiler does not need to see, nor evaluate non public imports in those di files. What do you think?
