new DIP47: Outlining member functions of aggregates

[Timon Gehr]

On 09/07/2013 07:00 PM, Walter Bright wrote:
> Outlining of member functions is the practice of placing the declaration
> of a member function in the struct/class/union, and placing the
> definition of it at global scope in the module or even in another module.
>
> http://wiki.dlang.org/DIP47

> Rationale:

I don't think that the official rationale should include 'readability', 
giving clear preference to one declaration style over the other.

> Semantics:

First of all, the DIP should address the following additional points:
- CTFE (under which circumstances is an outlined member function CTFE-able?)
- UDA's
- DDOC
- Auto return functions


> 1. Only member functions of aggregates at module scope can be outlined.

Why module scope? Why just member functions?


> 2. Types, parameter types, and pure/const/immutable/shared/nothrow attributes must match. This is necessary as they affect overloading and so are needed for correct selection of which declaration is being outlined.

Why would nothrow/pure affect overloading but @safe/static not?


> 3. Parameter names need not match.

OK. (But maybe it is better to require them to match if given in both 
places.)


> 4. If there is a default parameter value, it may only appear in the member function declaration.

Probably this is not too bad, but can't you just require the AST to match?


> 5. @safe/@trusted/@system, private/package/public/export access, linkage and storage classes are as set in the declaration, overriding any in effect for the definition.

Isn't the overriding just confusing for no reason?


> 6. Template member functions may not be outlined.

(This is included in point 1.)


> 7. Outlined member function return types, parameter types, and function bodies have private access to the module where the aggregate is declared.

The function names themselves are missing, and maybe you want the 
type-declaring module to have access to its private function bodies as 
well if it imports the implementing module. In any case, this is rather 
ugly. Why not use 'package' for this purpose and keep visibility rather 
simple? [1]



([1] Well, IMO 'protected' is quite hard to implement in a 
non-restrictive way in presence of compile-time reflection.)