Difference between revisions of "DIP47"

From D Wiki
Jump to: navigation, search
(initial version)
 
(grammar)
Line 24: Line 24:
 
== Abstract ==
 
== Abstract ==
  
Outlining of member functions is the practice of including on the declaration of a
+
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 appearing at global
 
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

  1. Only member functions of aggregates at module scope can be outlined.
  1. 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.

  1. Parameter names need not match.
  1. If there is a default parameter value, it may only appear in the member function declaration.
  1. @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.

  1. Template member functions may not be outlined.
  1. 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.