new DIP47: Outlining member functions of aggregates

[Walter Bright]

On 9/7/2013 12:30 PM, Andrej Mitrovic wrote:
> 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).

Good point.

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

How a function is to be *used* should be all there in the *declaration*. Not the 
definition.

I didn't mention it in the DIP, and should, that the reason for the default 
value to be in the declaration is 1. it should only depend on the declaration's 
scope and 2. because all uses of it should rely only on the declaration and 3. 
because making an exact duplicate of it in the definition is pointless.

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

No, see above.


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

I have mixed feelings about this. I think there needs to be just enough in the 
definition to match it to the declaration, and nothing else.