DIP47

Title:	Outline Member Functions of Aggregates
DIP:	47
Version:	1
Status:	Draft
Created:	2013-09-07
Last Modified:	2013-09-07
Author:	Walter Bright

Abstract

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.

Rationale

Not being able to outline member functions imposes a certain constraint on how source code is constructed. When encouraging translation of a project from C++ to D, one cannot have a 1:1 correspondence of C++ source layout to D layout. This raises the adoption barrier. With it, correspondence can be preserved.

It's the job of an IDE to collapse or expand function bodies. As Manu Evans explains, this is unfortunately not the only way source code is perused:

"If you rely on tools to make the code _readable_, not only has the language kinda failed at being a nice clean readable language, but you also can't easily read it easily outside the IDE. People read their code just as much in github commits, merge/diff windows, emails/chat, etc. I find code folding even worse in a way, since when you get used to code folding, you don't have a feel for the layout of the whole file when it's unfolded (diff windows, commit logs, etc), and it feels really foreign in these environments. You gain a sense of familiarity with the general shape of the code when working with it. Folding ruins that for me, and I still think it's a pointless bandaid on a problem that should have easily been avoided in the first place. Surely the proper angle is for the IDE to assist with authoring code, ie, fixing up the second function header when you change the first, or tapping a key to skip between the 2, which IDE's also usually offer."

Syntax

Outlining member function mfunc() would look like:

struct S {
    static int mfunc(int a, int b = 5) pure;	// member function declaration
}

int S.mfunc(int a, int b) pure {	// member function definition
    ...
}

Semantics

1. Only member functions of aggregates at module scope can be outlined.
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.
3. Parameter names need not match.
4. If there is a default parameter value, it may only appear in the member function declaration.
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.
6. Template member functions may not be outlined.
7. Outlined member function return types, parameter types, and function bodies have private access to the module where the aggregate is declared.

Existing Code

Outlining will not break any existing code.

Copyright

This document has been placed in the Public Domain.