Private default function arguments
Jesse Phillips
jessekphillips+D at gmail.com
Fri Jan 15 11:25:09 PST 2010
bearophile Wrote:
> int foo3(int x, private int depth=0) {
> ...
> foo3(x+1); // OK
> foo3(x, depth + 1); // OK
> ...
> }
> void main() {
> int r = foo3(5); // OK
> int r = foo3(5, 1); // Error
> int r = foo3(5, 0); // Error
> }
>
> Now the programmer is allowed to give/specify the "depth" argument only inside foo() itself :-)
> So the source code comment of foo1() is converted in foo3() into something that the compiler can enforce at compile-time.
>
> Bye,
> bearophile
I don't think this gains very much and brings about the question about what use is:
int foo4(int x, package int depth=0) {...}
Sure this could be invalid but it is more consistent if private is allowed.
But I think that you'll find many people will just do it like this even with that feature:
public int bar(int x) {
bar(x, 0);
}
private int bar(int x, int depth) { ... }
Documentation: you don't document the default depth. Yes make comments about it for those programming in that function, but bar(int x) is all that is needed for documentation.
Safe: Your complaint about the inner function doesn't seem to be a matter of safety (leaving off static won't crash or cause an incorrect result?).
Performance: One of D's goals is to make it easy to do the "right thing." I think performance can be part of this. Your complaint about static does fit here.
Clean: The degree your suggestion cleans up the code is minimal. I'm still trying to figure out what benefit Ruby's 'yield' gives one over passing a delegate to a function. It makes for cleaner code, but it seems to be a very simple concept that comes across as very complicated just because some magic stuff happens.
More information about the Digitalmars-d
mailing list