On 9/7/13, Walter Bright <newshou...@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.