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.)
