www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [typeof] exception for overloaded functions?

reply Manfred Nowak <svv1999 hotmail.com> writes:
[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
Sep 01 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
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?
Sep 01 2005
parent reply Chris Sauls <ibisbasenji gmail.com> writes:
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
Sep 01 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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?
Sep 01 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Sep 02 2005
prev sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----

iD8DBQFDH3BA3w+/yD4P9tIRAl6EAKCbcz434qjWzME4+lOse/ZCUPEftgCggreo
g082gLmTHMZreMMCiF7sGfs=
=7k4Y
-----END PGP SIGNATURE-----
Sep 07 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
=?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
Sep 07 2005