new DIP47: Outlining member functions of aggregates

[Andrej Mitrovic]

On 9/7/13, Walter Bright <newshound2 at digitalmars.com> wrote:
> 3. Parameter names need not match.

I disagree with this, because it will practically guarantee that
declarations and definitions go out of sync, which will be *harmful*
for readability (which is partly what this DIP is all about).

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

Also disagreed, because again you can't tell how a function can be
called just by looking at its definition, now you have to go back and
forth between the declaration and the definition to fully understand
how the function works and how it can be used.

On the other hand, allowing both the declaration and the definition to
have the default values (which must match of course) might have issues
with readability as well:

module a;

enum val = 1;
struct S { void test(int x = val); }

module a_impl;

enum val = 2;
void S.test(int x = val);  // a.val or a_impl.val?

If 'val' will always refer to a.val in the declaration module, then
there's no conflict, however it does create a bit of a readability
issue.

Still, I think default values should appear at both sides. It's very
easy to forget you've defaulted a parameter when you start
implementing the function, you could even implement it wrongly.

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

They should both match or there should be an error. Don't allow sloppy
code to be written like that, people *will* read both the declarations
and the definitions (the team or contributors in an open-source
project), and any mismatch will only cause confusion.