"Don Clugston" <Don_member@pathlink.com> wrote in message news:dcs261$2ad4$1@digitaldaemon.com...
>
>>I am inclined to agree with you regarding the problem (limitation) you
>>mentioned
>>in line "C." At the same time, I'm not so fond of your solution for 2
>>reasons:
>>
>>1) Performance: Adding extra function calls would slow things down.
>
> They're just trivial inline functions. If the optimiser can't inline them,
> it is
> an extremely poor optimiser. It's one of the most trivial optimisations
> you can
> make.

If the functions are methods in a class the optimizer can't inline them since they might be overridden in a subclass (unless the user code is simple enough that the compiler can determine the runtime type and not treat the method call as a virtual dispatch).

Hi,

>AJG wrote:
>> Hm... I believe non-constant expressions are already allowed:
>> 
>> int Bar() { return (0); }
>> int Foo(int b = Bar() % 2) { return (b); }
>> void main() { Foo(); } // Compiles fine.
>
>But not if they refer to other arguments, which I think is an important/very useful feature. E.g. in the following function signatures it'd be quite handy:
>
>int foo(int x, int y = x % 2)
>int bar(int[] a, int b = a.length)

Yes, yes it would. If I may throw a wild guess about why that's not currently allow: It could be that argument evaluation order is not guaranteed (just like in C), therefore it might not know A before B.

If that's the case, I say please get rid of this archaic restriction and once and for all guarantee left-to-right evaluation, which might then allow what you propose to be work.

IIRC, the original C non-guarantee was due to some limitation of the architecture of the PDP-11, so it seems majestically anachronistic to maintain it.

>Currently neither compiles. This (along with every other problem) can be solved using overloading, but that is a _pain_. After all, default arguments should IMO be just syntactic sugar for precisely that, as in the original proposal.

I don't really care too much about the underlying implementation as long as it accomplishes the goal and it's not terribly inefficient.

>So this is my #1 gripe related to default arguments.
>Inability to use members as defaults in a class, which you already
>brought earlier, would be #2.
>#3 is the problem with function pointers in the original post, but
>fortunately I haven't personally run into that problem yet. <g>

I haven't either.

>I don't really mind not being able to skip defaults, although something like writing "default" in place of a function parameter would doubtless be handy.

By "skip" I mean anything that allows such behaviour. This could be done (syntactically) with just successive commas:

# Foo(arg1, , arg3, , arg5);

Or with a "default" or "skip" keyword:

# Foo(arg1, default, arg3, default, arg5);

Or perhaps with a symbol:

# Foo(arg1, ?, arg3, ?, arg5);

Or any other similar way. Whatever's easiest to implement. I would just want the actual functionality. This too IMO would be quite handy.

Cheers,
--AJG.

AJG wrote:

>>int foo(int x, int y = x % 2)
>>int bar(int[] a, int b = a.length)
> 
> 
> Yes, yes it would. If I may throw a wild guess about why that's not currently
> allow: It could be that argument evaluation order is not guaranteed (just like
> in C), therefore it might not know A before B. 

int foo(int x, int y = foo(x))

what now?

-- Georg

In article <dcs6d5$2ef3$1@digitaldaemon.com>, AJG says...

>>Each possible function signature that uses any default parameters is as a stub that just rearranges the stack and does a goto to the normal maybe even inside some of the intro code.
>
>Would this allow for skipping parameters, or would it create the 2^N scenario? Or would that not matter?

Yes parameter skipping would be allowed (possible) with this scheme. The problem would be ambiguity e.g.

Foo(int a, int b=1, int c=2)

Foo(1, 0); // Foo(a,b) or Foo(a,c)



One possibility would be allowing explicit creation of stubs e.g.



Foo(int a, int b)
{
return a+b;
}
stub(int a)
{
b=0;
}
stub(real r)
{
a=cast(int)r;
b=cast(int)r*2;
}

or something like that

Hi,

>>>int foo(int x, int y = x % 2)
>>>int bar(int[] a, int b = a.length)
>> 
>> 
>> Yes, yes it would. If I may throw a wild guess about why that's not currently allow: It could be that argument evaluation order is not guaranteed (just like in C), therefore it might not know A before B.
>
>int foo(int x, int y = foo(x))

IIRC recursive default parameter definitions cause an out of memory fault or somesuch in the compiler - whether they use previous parameters or not. So the point is moot. E.g.:

# int foo(int x = foo()) {}

Cheers,
--AJG.

Hi,

>>>Each possible function signature that uses any default parameters is as a stub that just rearranges the stack and does a goto to the normal maybe even inside some of the intro code.
>>
>>Would this allow for skipping parameters, or would it create the 2^N scenario? Or would that not matter?
>
>Yes parameter skipping would be allowed (possible) with this scheme. The problem would be ambiguity e.g.
>
>Foo(int a, int b=1, int c=2)
>
>Foo(1, 0); // Foo(a,b) or Foo(a,c)

Hm... I see no ambiguity here. Foo(1, 0) can only be Foo(a, b). To get Foo(a, c)
you'd have to do:

Foo(1, , 0); or
Foo(1, default, 0); or
Foo(1, ?, 0);

Or whatever syntax is eventually selected. But the key is that there should be a placeholder. That alone removes the ambiguities.

Cheers,
--AJG.


>
>
>One possibility would be allowing explicit creation of stubs e.g.
>
>
>
>Foo(int a, int b)
>{
>return a+b;
>}
>stub(int a)
>{
>b=0;
>}
>stub(real r)
>{
>a=cast(int)r;
>b=cast(int)r*2;
>}
>
>or something like that
>
>

AJG wrote:

>>int foo(int x, int y = foo(x))
> 
> 
> IIRC recursive default parameter definitions cause an out of memory fault or
> somesuch in the compiler - whether they use previous parameters or not.

The compiler is fine with the following indirect recursion,
but the executable runs in an infinite loop until segmentation
fault.
Seems like the practical programmer is in charge ;-)

int bar()
{
        return foo(42);
}

int foo(int x, int y = bar())
{
        return 0;
}

int main()
{
        return foo(3);
}