I mentioned this before. It seems such a simple thing, too.

I really think it's important that opCast() take a dummy parameter so that we can overload on it, because you can't overload on the return type. Then, for example, I would be able to do:

>       class Int
>       {
>           int opCast(int dummy) { return toInt(); }
>           long opCast(long dummy) { return toLong(); }
>           double opCast(double dummy) { return toDouble(); }
>       }

and so on. Without this, opCast is practically useless. This would be such an easy thing to add, would it not? It would certainly be of great benefit.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca3pj5$2cu$1@digitaldaemon.com...
> I mentioned this before. It seems such a simple thing, too.

And this time I will also agree!

> I really think it's important that opCast() take a dummy parameter so that
we
> can overload on it, because you can't overload on the return type. Then,
for
> example, I would be able to do:
>
> >       class Int
> >       {
> >           int opCast(int dummy) { return toInt(); }
> >           long opCast(long dummy) { return toLong(); }
> >           double opCast(double dummy) { return toDouble(); }
> >       }
>
> and so on. Without this, opCast is practically useless. This would be such
an
> easy thing to add, would it not? It would certainly be of great benefit.
>
> Jill
>
>
>

On Tue, 8 Jun 2004 07:24:21 +0000 (UTC), Arcane Jill wrote:

> I mentioned this before. It seems such a simple thing, too.
> 
> I really think it's important that opCast() take a dummy parameter so that we can overload on it, because you can't overload on the return type. Then, for example, I would be able to do:
> 
>>       class Int
>>       {
>>           int opCast(int dummy) { return toInt(); }
>>           long opCast(long dummy) { return toLong(); }
>>           double opCast(double dummy) { return toDouble(); }
>>       }
> 
> and so on. Without this, opCast is practically useless. This would be such an easy thing to add, would it not? It would certainly be of great benefit.
> 
> Jill

Not to be able to overload opCast() does seem a bit pointless. So I agree
with you AJ.

BTW, its been a while since I've seen the rationale for not overloading based on return type. Can somebody refresh me on this point?


-- 
Derek
Melbourne, Australia
8/Jun/04 6:10:18 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:ca3shk$85s$1@digitaldaemon.com...
> On Tue, 8 Jun 2004 07:24:21 +0000 (UTC), Arcane Jill wrote:
>
> > I mentioned this before. It seems such a simple thing, too.
> >
> > I really think it's important that opCast() take a dummy parameter so
that we
> > can overload on it, because you can't overload on the return type. Then,
for
> > example, I would be able to do:
> >
> >>       class Int
> >>       {
> >>           int opCast(int dummy) { return toInt(); }
> >>           long opCast(long dummy) { return toLong(); }
> >>           double opCast(double dummy) { return toDouble(); }
> >>       }
> >
> > and so on. Without this, opCast is practically useless. This would be
such an
> > easy thing to add, would it not? It would certainly be of great benefit.
> >
> > Jill
>
> Not to be able to overload opCast() does seem a bit pointless. So I agree
> with you AJ.
>
> BTW, its been a while since I've seen the rationale for not overloading based on return type. Can somebody refresh me on this point?
>

int func(){return 3;}
char[] func(){return "Hello";}

func(); //which one to call?


> --
> Derek
> Melbourne, Australia
> 8/Jun/04 6:10:18 PM

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca3pj5$2cu$1@digitaldaemon.com...
> I mentioned this before. It seems such a simple thing, too.
>
> I really think it's important that opCast() take a dummy parameter so that
we
> can overload on it, because you can't overload on the return type. Then,
for
> example, I would be able to do:
>
> >       class Int
> >       {
> >           int opCast(int dummy) { return toInt(); }
> >           long opCast(long dummy) { return toLong(); }
> >           double opCast(double dummy) { return toDouble(); }
> >       }
>
> and so on. Without this, opCast is practically useless. This would be such
an
> easy thing to add, would it not? It would certainly be of great benefit.
>
> Jill
>

I suggested using an out parameter instead of return value, like this:

class Int
{
   void opCast(out int result) { result = 3; }
   void opCast(out real result) { result = 3.0; }
}

So at least it doesn't look like a hack ;)

In article <ca4kdc$1k59$1@digitaldaemon.com>,
 "Vathix" <vathixSpamFix@dprogramming.com> wrote:
> 
> I suggested using an out parameter instead of return value, like this:
> 
> class Int
> {
>    void opCast(out int result) { result = 3; }
>    void opCast(out real result) { result = 3.0; }
> }
> 
> So at least it doesn't look like a hack ;)

...well, a lot of things in C++ don't look like hacks until you start reading the standard very carefully.

To me the strangest part is that the function will behave as if it contained a return statement.

So I guess it boils down to this:

1) is everybody ok with that lie?  I don't think we should be, because it will inhibit people's ability to understand code. 2) how hard is it for compiler writers to handle this special case where there is a textually declared "void" return type but an implied cast-to return type and an implied "return" statement?  My guess is that, although it may not seem hard, we can get into trouble if we start accepting features that mean the opposite of what is implied by the syntax.

IMHO, a return type of "void" should mean "this function returns void".

I vote for Jill's suggestion -- not that I actually have a vote. :-)

One thing though, about Jill's example: since "dummy" is not used, need it be used in the opCast definition at all?

On the other hand, would we be able to use "dummy" and expect that it contains the default initializer value for its type at the entry point of the function?

On Tue, 8 Jun 2004 10:58:30 +0200, Ivan Senji wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:ca3shk$85s$1@digitaldaemon.com...
>> On Tue, 8 Jun 2004 07:24:21 +0000 (UTC), Arcane Jill wrote:
>>
>>> I mentioned this before. It seems such a simple thing, too.
>>>
>>> I really think it's important that opCast() take a dummy parameter so
> that we
>>> can overload on it, because you can't overload on the return type. Then,
> for
>>> example, I would be able to do:
>>>
>>>>       class Int
>>>>       {
>>>>           int opCast(int dummy) { return toInt(); }
>>>>           long opCast(long dummy) { return toLong(); }
>>>>           double opCast(double dummy) { return toDouble(); }
>>>>       }
>>>
>>> and so on. Without this, opCast is practically useless. This would be
> such an
>>> easy thing to add, would it not? It would certainly be of great benefit.
>>>
>>> Jill
>>
>> Not to be able to overload opCast() does seem a bit pointless. So I agree
>> with you AJ.
>>
>> BTW, its been a while since I've seen the rationale for not overloading based on return type. Can somebody refresh me on this point?
>>
> 
> int func(){return 3;}
> char[] func(){return "Hello";}
> 
> func(); //which one to call?

Ah yes - the old "functions are assumed to return an int if the call is not explictly coded otherwise" trick.

So how about, in the case of ambiguity (such as above), the compiler just
tells you about it (error-abort) until you tell it explicitly...

  int a;
  a = func()

or

  cast(int)func();

This resolution of ambiguity would only be needed where it actually existed, much like operator overloading now.

-- 
Derek
Melbourne, Australia

What about:

    class Int
    {
        opCast(int)() { result = 3; }
        opCast(real)() { result = 3.0; }
    }

"James Widman" <james@jwidman.com> wrote in message news:james-D93ECD.13022008062004@digitalmars.com...
> In article <ca4kdc$1k59$1@digitaldaemon.com>,
>  "Vathix" <vathixSpamFix@dprogramming.com> wrote:
> >
> > I suggested using an out parameter instead of return value, like this:
> >
> > class Int
> > {
> >    void opCast(out int result) { result = 3; }
> >    void opCast(out real result) { result = 3.0; }
> > }
> >
> > So at least it doesn't look like a hack ;)
>
> ...well, a lot of things in C++ don't look like hacks until you start reading the standard very carefully.
>
> To me the strangest part is that the function will behave as if it contained a return statement.
>
> So I guess it boils down to this:
>
> 1) is everybody ok with that lie?  I don't think we should be, because
> it will inhibit people's ability to understand code.
> 2) how hard is it for compiler writers to handle this special case where
> there is a textually declared "void" return type but an implied cast-to
> return type and an implied "return" statement?  My guess is that,
> although it may not seem hard, we can get into trouble if we start
> accepting features that mean the opposite of what is implied by the
> syntax.
>
> IMHO, a return type of "void" should mean "this function returns void".
>
> I vote for Jill's suggestion -- not that I actually have a vote. :-)
>
> One thing though, about Jill's example: since "dummy" is not used, need it be used in the opCast definition at all?
>
> On the other hand, would we be able to use "dummy" and expect that it contains the default initializer value for its type at the entry point of the function?

On Wed, 9 Jun 2004 07:50:15 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> What about:
>
>     class Int
>     {
>         opCast(int)() { result = 3; }
>         opCast(real)() { result = 3.0; }
>     }

Nice, but I think

     class Int
     {
         int opCast()  { return 3; }
         real opCast() { return 3.0; }
     }

looks better. I realise you cannot overload on return type, but 'opCast' could be a special case where the compiler actually turns what I have above, into what Matthew has above above.

Regan

> "James Widman" <james@jwidman.com> wrote in message
> news:james-D93ECD.13022008062004@digitalmars.com...
>> In article <ca4kdc$1k59$1@digitaldaemon.com>,
>>  "Vathix" <vathixSpamFix@dprogramming.com> wrote:
>> >
>> > I suggested using an out parameter instead of return value, like this:
>> >
>> > class Int
>> > {
>> >    void opCast(out int result) { result = 3; }
>> >    void opCast(out real result) { result = 3.0; }
>> > }
>> >
>> > So at least it doesn't look like a hack ;)
>>
>> ...well, a lot of things in C++ don't look like hacks until you start
>> reading the standard very carefully.
>>
>> To me the strangest part is that the function will behave as if it
>> contained a return statement.
>>
>> So I guess it boils down to this:
>>
>> 1) is everybody ok with that lie?  I don't think we should be, because
>> it will inhibit people's ability to understand code.
>> 2) how hard is it for compiler writers to handle this special case where
>> there is a textually declared "void" return type but an implied cast-to
>> return type and an implied "return" statement?  My guess is that,
>> although it may not seem hard, we can get into trouble if we start
>> accepting features that mean the opposite of what is implied by the
>> syntax.
>>
>> IMHO, a return type of "void" should mean "this function returns void".
>>
>> I vote for Jill's suggestion -- not that I actually have a vote. :-)
>>
>> One thing though, about Jill's example: since "dummy" is not used, need
>> it be used in the opCast definition at all?
>>
>> On the other hand, would we be able to use "dummy" and expect that it
>> contains the default initializer value for its type at the entry point
>> of the function?
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Or

     class Int
     {
         int opCast() { result = 3; }
         real opCast() { result = 3.0; }
     }


"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:ca5cel$2ug7$1@digitaldaemon.com...
> What about:
>
>     class Int
>     {
>         opCast(int)() { result = 3; }
>         opCast(real)() { result = 3.0; }
>     }
>
> "James Widman" <james@jwidman.com> wrote in message news:james-D93ECD.13022008062004@digitalmars.com...
> > In article <ca4kdc$1k59$1@digitaldaemon.com>,
> >  "Vathix" <vathixSpamFix@dprogramming.com> wrote:
> > >
> > > I suggested using an out parameter instead of return value, like this:
> > >
> > > class Int
> > > {
> > >    void opCast(out int result) { result = 3; }
> > >    void opCast(out real result) { result = 3.0; }
> > > }
> > >
> > > So at least it doesn't look like a hack ;)
> >
> > ...well, a lot of things in C++ don't look like hacks until you start reading the standard very carefully.
> >
> > To me the strangest part is that the function will behave as if it contained a return statement.
> >
> > So I guess it boils down to this:
> >
> > 1) is everybody ok with that lie?  I don't think we should be, because
> > it will inhibit people's ability to understand code.
> > 2) how hard is it for compiler writers to handle this special case where
> > there is a textually declared "void" return type but an implied cast-to
> > return type and an implied "return" statement?  My guess is that,
> > although it may not seem hard, we can get into trouble if we start
> > accepting features that mean the opposite of what is implied by the
> > syntax.
> >
> > IMHO, a return type of "void" should mean "this function returns void".
> >
> > I vote for Jill's suggestion -- not that I actually have a vote. :-)
> >
> > One thing though, about Jill's example: since "dummy" is not used, need it be used in the opCast definition at all?
> >
> > On the other hand, would we be able to use "dummy" and expect that it contains the default initializer value for its type at the entry point of the function?
>
>