On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
Perhaps then, what I think is the most significant point of all is being missed. I can see a very clear reason why in terms of source code, the interface and implementation must not be be separated. Automated .di generation is a means to solve the need for separation when distributing libraries, whoever what goes in the .di should not be considered as your "source code" because it should be auto generated from the source (eg your .o files are not source code in the same way). I
I agree with Rob T on this point. Being free from the burden of maintaining an interface file was one of the selling points of D vs. C++ for me - repeating the same changes over and over in the .cpp and .h file was a pointless distraction and strain on my productivity, especially during prototyping.
Even though the feature, if introduced, will be optional, sooner or later it will end up in a library (likely, written by a misguided programmer coming from C++), and I will have to debug it - so I don't consider "don't use it if you don't like it" a real argument.
Also, I don't think that we should consider that a class declaration is the same thing as the class interface - for the simple reason that a class declaration must also contain private fields and methods. Having to recompile half of my program just because of a signature change in a class's private method makes no sense, and is the reason why hacks like PImpl emerged.
