Difference between revisions of "DIP47"
WalterBright (talk | contribs) (initial version) |
WalterBright (talk | contribs) (grammar) |
||
| Line 24: | Line 24: | ||
== Abstract == | == Abstract == | ||
| − | Outlining of member functions is the practice of | + | 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. |
| − | member function in the struct/class/union, and the definition of it | ||
| − | scope in the module or even in another module. | ||
== Rationale == | == Rationale == | ||
Revision as of 16:59, 7 September 2013
| 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
- Only member functions of aggregates at module scope can be outlined.
- 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.
- Parameter names need not match.
- If there is a default parameter value, it may only appear in the member function declaration.
- @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.
- Template member functions may not be outlined.
- 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.
