new DIP47: Outlining member functions of aggregates

[Andrej Mitrovic]

On 9/7/13, Walter Bright <newshound2 at digitalmars.com> wrote:
> How a function is to be *used* should be all there in the *declaration*. Not the definition.

I mean the *header* part of the function's definition (everything up
to the closing parens of the parameter list). If someone is currently
looking at an implementation file:

void S.foo(int x) { ... }

They will assume 'x' must be specified.

You can argue that people shouldn't be looking at the implementation,
but do have in mind two things:

1. This new feature is *optional*, meaning people will still look at
the implementation for guidance, and not all new library writers will
take advantage of this new feature.

This has the consequence that a user looking at a function called
"foo", and looking at one called "S.foo" will have to be careful not
to assume that "S.foo" documents the parameter list properly (because
it can mismatch the declaration if you allow default arguments to be
missing).

2. People are already used to looking at implementation files and
method implementations in almost all public D projects. Header files
have not proven to be popular among D projects.

> 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

The code in the function's body already depends on the declaration's
scope. It would be a little strange if the body of the function has
access to one scope, but the parameter list has either no scope or a
different scope.