new DIP47: Outlining member functions of aggregates

[PauloPinto]

On Monday, 9 September 2013 at 12:28:54 UTC, Dicebot wrote:
> On Monday, 9 September 2013 at 00:43:39 UTC, H. S. Teoh wrote:
>> Therefore, the *real* solution to this problem is to fix the 
>> compiler's
>> .di output to give a proper overview of the class 
>> *automatically*, and
>> nicely pretty-printed.
>
> Yes, that should be superior approach in general though exact 
> usability is very detail-specific - currently relation between 
> .di and .d and not really well-defined and pulling this off 
> will requires its own DIP at the very least.
>
> For example, it is not entirely clear to me, what should happen 
> if there are both .di and .d files in the file system at the 
> same time and they have minor difference (remember, it is 
> perfectly legal to tweak .di manually). It is likely, that 
> improving .di tool chain will require similar signature 
> matching verification anyway. Also I am wondering how to differ 
> purely auto-generated .di files (should be updated completely 
> upon build) and ones with manual changes (should be only 
> verified).
>
> It is all about small details.

In languages like Modula-2, it is a compile error if there are 
differences.

So I would say D compilers should follow the same behavior, 
unless it is requested to generate .di files automatically, which 
will then overwrite the corresponding .di files.