Anders Juul Munch (juul@diku.dk) wrote:
: miket@world.std.com (Michael Trachtman) writes:

: >The standard reason why signatures by return type are not allowed is:

: >int f()
: >float f()

: >   f()  // which f should be invoked ?

: >Now, since name spaces are being added to the language, why not
: >make the previous a compile error.
: >However, you could say the following:
: >   int::f()

: >   or float::f()

: >  which would give the right one.

: ...and add new confusion for compiler writers as well as C++ programmers, as
: the :: operator takes an additional meaning.

: A f();
: class A
: {
:  f();
:  g() { A::f(); } // which f should be invoked ?
: };

I concede the syntax ambiguity.
However, the question remains the same. Differentiating by type is still
useful. Especially in templates. I have more than once, added dummy
arguments to a function, just to cause it to differ from another identically
named function with a different return type.

Things like:
template<T> T func(int x, T dummy) ...

#define Xfunc(x, type) func(x, (type) 0)

and then I use Xfunc as:  int z = Xfunc(3, int);
or some_other_type zz = Xfunc(3, some_other_type);

Finding a non ambiguous, backwards compatible syntax should be possible
even if it is difficult to (without adding new keywords).

Michael T.

In article <CLIwss.Av5@world.std.com> miket@world.std.com (Michael Trachtman) writes:
>Anders Juul Munch (juul@diku.dk) wrote:
>: miket@world.std.com (Michael Trachtman) writes:
>
>: >The standard reason why signatures by return type are not allowed is:
>
>: >int f()
>: >float f()
>
>: >   f()  // which f should be invoked ?
>
>: >Now, since name spaces are being added to the language, why not
>: >make the previous a compile error.
>: >However, you could say the following:
>: >   int::f()
>
>: >   or float::f()
>
>: >  which would give the right one.
>
>: ...and add new confusion for compiler writers as well as C++ programmers, as
>: the :: operator takes an additional meaning.
>
>: A f();
>: class A
>: {
>:  f();
>:  g() { A::f(); } // which f should be invoked ?
>: };
>
>I concede the syntax ambiguity.
>However, the question remains the same. Differentiating by type is still
>useful. Especially in templates. I have more than once, added dummy
>arguments to a function, just to cause it to differ from another identically
>named function with a different return type.
>
>Things like:
>template<T> T func(int x, T dummy) ...
>
>#define Xfunc(x, type) func(x, (type) 0)
>
>and then I use Xfunc as:  int z = Xfunc(3, int);
>or some_other_type zz = Xfunc(3, some_other_type);

Why not use this?
   template<class T>
      struct func {
         static T call(int x) { ... };
      };

   int i     = func<int>::call(42);
   Complex c = func<Complex>::call(69);


>
>Finding a non ambiguous, backwards compatible syntax should be possible
>even if it is difficult to (without adding new keywords).
>
>Michael T.


Take care
    Robert
--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

The standard reason why signatures by return type are not allowed is:

int f()
float f()

   f()  // which f should be invoked ?

Now, since name spaces are being added to the language, why not
make the previous a compile error.
However, you could say the following:
   int::f()

   or float::f()

  which would give the right one.

Of course, the following would also be made to work...

    int x = f();
     or
    int x;  x = f();

This would be done by having implicit defined overloading for operators=
etc.

This makes the syntax for builtin types almost like for classes.

i.e. there is mytype::f() as well as int::f().
However, it uses the namespace mechanism instead of the class mechanism.

To extend this to the almost absurd, we could even allow:

  int x;
  float x;   // this is a different x;
  int y;
  y = x;  // this means y=int::x;
  float y;   // ok, this is a different y.
  y = int::x;   // I want the int:x converted to a float.


This would not break any existing code.
Having similar functions whose signature differs by return type is
a common request and would probably not cause  confusion.

Having identically named variables whose type differs is not a common
request and may (or may not) lead to confusion, however it lends
orthogonality to the language.

Am I totally out of my mind ??

Michael T.

miket@world.std.com (Michael Trachtman) writes:

>The standard reason why signatures by return type are not allowed is:

>int f()
>float f()

>   f()  // which f should be invoked ?

>Now, since name spaces are being added to the language, why not
>make the previous a compile error.
>However, you could say the following:
>   int::f()

>   or float::f()

>  which would give the right one.

...and add new confusion for compiler writers as well as C++ programmers, as
the :: operator takes an additional meaning.

A f();
class A
{
 f();
 g() { A::f(); } // which f should be invoked ?
};

>Am I totally out of my mind ??

Now that you mention it ...  :-)

Anders Munch  |  Department of Computer Science
juul@diku.dk  |  University of Copenhagen, Denmark
Still confused but at a higher level

miket@world.std.com (Michael Trachtman) writes:

>int f()
>float f()
>
>   f()  // which f should be invoked ?

>However, you could say the following:
>   int::f()
>
>   or float::f()
>
>  which would give the right one.

The syntax `T::foo' already has a meaning.
Attempting to give in another different meaning would be
very confusing, to say the least.

 struct A {};
 struct B {
  static A foo();
 };
 A foo();
 B foo();

 int main() {
  B::foo(); // which foo()?
  return 0;
 }

C++ is complex enough already without worrying about overloading
on return types.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au