new DIP47: Outlining member functions of aggregates

[Paulo Pinto]

Am 09.09.2013 16:36, schrieb H. S. Teoh:
> On Mon, Sep 09, 2013 at 03:26:23PM +0200, PauloPinto wrote:
>> 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).
>
> I'd propose to make it such that you *don't* have to tweak the .di
> manually. Maybe the use of UDAs could help get rid of the need to edit
> .di by hand, by instructing the compiler what kind of output is desired.
>
> Anything that requires hand-tweaking is unreliable and prone to errors
> and careless bugs. The best way is to have .di completely automated.
>
>
>>> 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.
>
> I think it is a bug for the .di and .d to have mismatches. For example,
> I don't see how the following code could be correct:
>
> 	---module.di---
> 	int func(int x) pure;
>
> 	---module.d---
> 	int global;
> 	int func(int x) { return global; }
>
> Any such mismatch should be considered a bug.
>
> In fact, the current lax enforcement of matching makes it possible for
> something to be declared pure @safe nothrow in .di, but impure @system
> throwing in .d. I think there has been a few bugs like this in druntime
> that got fixed.
>
>
> T
>


I should have read your earlier post better.

The better approach would then be like the compilers of the Oberon 
language family do, by generating the interface file when compiling the 
packages.

--
Paulo