[typeof] exception for overloaded functions?

<code>
real f(){ return 1.0l;}
int f( int i){ return 0;}
void main(){
  typeof(&f) g= &f;
  f( 1); // ok
  g( 1); // Error: expected 0 arguments, not 1
}
</code>


-manfred

Manfred Nowak wrote:
> [typeof] exception for overloaded functions?
> 
> <code>
> real f(){ return 1.0l;}
> int f( int i){ return 0;}
> void main(){
>   typeof(&f) g= &f;
>   f( 1); // ok
>   g( 1); // Error: expected 0 arguments, not 1
> }
> </code>
> 
> 
> -manfred

What's wrong with the error message? What did you expect?

zwang wrote:
> Manfred Nowak wrote:
> 
>> [typeof] exception for overloaded functions?
>>
>> <code>
>> real f(){ return 1.0l;}
>> int f( int i){ return 0;}
>> void main(){
>>   typeof(&f) g= &f;
>>   f( 1); // ok
>>   g( 1); // Error: expected 0 arguments, not 1
>> }
>> </code>
>>
>>
>> -manfred
> 
> 
> What's wrong with the error message? What did you expect?

I think he's looking for a way to specify which 'f' he wants the address of, and/or for D to automagically reference function overloads via function pointers.  I'm not so sure about the latter (although a construct that could encompass all of a function's overloads would be nifty) but the former certainly should be available.

-- Chris Sauls

Chris Sauls wrote

[...]
> I think he's looking for a way to specify which 'f' he wants the address of, and/or for D to automagically reference function overloads via function pointers.  I'm not so sure about the latter (although a construct that could encompass all of a function's overloads would be nifty) but the former certainly should be available.
[...]

The latter is a deviation from the specs for `typeof', which do not contain any special treatment for overloaded functions, whereas special treatments for `this' and `super' are mentioned.

Therefore I expected, that by using `typeof( &f)' one gets the multitude of types, that are present in an overloaded function. But in the current implementation one seems to get only that from the list of overloads, which lexically comes first.

That appears wrong to me, because the D-way in "ctod.html" states | Functions can be defined in any order.

Therefore a change in the order of the overloads should not have any impact on the validity of the code in the same module or modules that import the overloads.

But as the example shows the order of the overloads _is_ relevant.

Therefore its a bug according to the specs.

-manfred

P.S.:
To specify a specific of the multitude of overloads, one can
already simply state its type explicitely. Therefore choosing
exactly one is troublefree. Choosing more than one, but not
all, can be done by specifying the ones wanted explicitely.
Choosing all can also be done with an alias, but why this
discontinuity?

Manfred Nowak wrote:
<snip>
> Therefore I expected, that by using `typeof( &f)' one gets the multitude of types, that are present in an overloaded function.  But in the current implementation one seems to get only that from the list of overloads, which lexically comes first.

A function pointer has only one signature.  The pointer can point only to a function that has this signature.  Function overloads are resolved at compiletime, not at runtime.

As such, your code ought to be a compiler error.

It would be possible, however, to invent overloaded function pointer types.  Then your code would compile to the equivalent of this:

----------
real f() { return 1.0l; }
int f(int i) { return 0; }

struct OFP {
    real function() f1;
    int function(int) f2;
}

void main() {
    OFP g; g.f1 = &f; g.f2 = &f;
    f(1);
    g.f2(1);
}
----------

But if we were to build in overloaded function pointers, which would give your code the semantics you suggest, then there ought to be a way of specifying the list of signatures directly.  Moreover, what if the function name you assign to the OFP has some but not all of the requested signatures?  Would it be a compile error, pad with nulls, or not alter these members?  And would there be a way to tweak the individual members of the OFP?

> To specify a specific of the multitude of overloads, one can already simply state its type explicitely. Therefore choosing
> exactly one is troublefree. Choosing more than one, but not all, can be done by specifying the ones wanted explicitely.  Choosing all can also be done with an alias, but why this discontinuity?

True, aliases are also resolved at compiletime, but they only exist at compiletime.  There is no runtime information associated with an alias as there is with a function pointer.  The compiler maps them to the correct overloaded version there and then.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Manfred Nowak schrieb:

> [typeof] exception for overloaded functions?
> 
> <code>
> real f(){ return 1.0l;}
> int f( int i){ return 0;}
> void main(){
>   typeof(&f) g= &f;
>   f( 1); // ok
>   g( 1); // Error: expected 0 arguments, not 1
> }
> </code>

Added to DStress as http://dstress.kuehne.cn/nocompile/t/typeof_07_A.d http://dstress.kuehne.cn/nocompile/t/typeof_07_B.d http://dstress.kuehne.cn/nocompile/t/typeof_07_C.d http://dstress.kuehne.cn/nocompile/p/pointer_01_A.d http://dstress.kuehne.cn/nocompile/p/pointer_01_B.d

Thomas

=?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= wrote:

[...]
> http://dstress.kuehne.cn/nocompile/t/typeof_07_B.d http://dstress.kuehne.cn/nocompile/t/typeof_07_C.d
[...]

Seems to be the same.

-manfred