Private default function arguments

[Nick Sabalausky]

"Jesse Phillips" <jessekphillips+D at gmail.com> wrote in message 
news:hiqfel$1i3s$1 at digitalmars.com...
> 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) {...}
>

Another question it brings up: What about this?

class Foo
{
    void bar(private int x=0) { ... }
    void whee()
    {
        // Allowed? And if not, should the feature be extended
        // to have a way to allow this while disallowing it outside Foo?
        bar(17);
    }
}

I'm not entirely opposed to the idea, but I think it would still need more 
thought put into it and would end up being only a minor improvement over 
just using a private overload.

I do think though, that the whole system of access modifiers could use to be 
re-thought. Something like what someone said about Scala's system would be a 
good thing to think about (to provide maximum flexibility without making the 
world of access modifiers more complicated than it already is in D), and 
also what someone said about adding a "true" private, plus there should be a 
clean way to de-couple specifications of read-access and write-access (ex, 
to allow read-only members without hacking them in with properties).