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