• Tim M (8/8) Nov 11 2008 http://www.digitalmars.com/d/2.0/operator-overloading.html#Unary
• Hxal (5/15) Nov 11 2008 That's actually very easy to sidestep, just instead of using opCast - us...
• Lars Kyllingstad (7/25) Nov 11 2008 I think the most elegant solution -- and this is not my idea, it has
• Brian (3/8) Nov 12 2008 except templates arent virtual, i think the simplest method is to have

"Tim M" <a b.com> writes:

http://www.digitalmars.com/d/2.0/operator-overloading.html#Unary

"The member function e.opCast() is called, and the return value of  
opCast() is implicitly converted to type. Since functions cannot be  
overloaded based on return value, there can be only one opCast per struct  
or class."

I've come across a situation where opcast to different types would be very  
useful. Why can't this be overloaded to cast to different types as a  
special situation for overloading on return types. Very useful IMHO.

Hxal <hxal freenode.irc> writes:

Tim M Wrote:
 http://www.digitalmars.com/d/2.0/operator-overloading.html#Unary
 
 "The member function e.opCast() is called, and the return value of  
 opCast() is implicitly converted to type. Since functions cannot be  
 overloaded based on return value, there can be only one opCast per struct  
 or class."
 
 I've come across a situation where opcast to different types would be very  
 useful. Why can't this be overloaded to cast to different types as a  
 special situation for overloading on return types. Very useful IMHO.

That's actually very easy to sidestep, just instead of using opCast - use a
method
like T Foo.to!(T) or a library solution like tango.util.Convert.

I do hope though that this restriction will be lifted when opImplicitCast comes
along, by choosing a signature that takes the target type as parameter.

Lars Kyllingstad <public kyllingen.NOSPAMnet> writes:

Hxal wrote:
 Tim M Wrote:
 http://www.digitalmars.com/d/2.0/operator-overloading.html#Unary

 "The member function e.opCast() is called, and the return value of  
 opCast() is implicitly converted to type. Since functions cannot be  
 overloaded based on return value, there can be only one opCast per struct  
 or class."

 I've come across a situation where opcast to different types would be very  
 useful. Why can't this be overloaded to cast to different types as a  
 special situation for overloading on return types. Very useful IMHO.

 
 That's actually very easy to sidestep, just instead of using opCast - use a
method
 like T Foo.to!(T) or a library solution like tango.util.Convert.
 
 I do hope though that this restriction will be lifted when opImplicitCast comes
 along, by choosing a signature that takes the target type as parameter.
 

I think the most elegant solution -- and this is not my idea, it has 
been mentioned here several times before -- would be to be able to use 
templates for operator overloading. Then one could write stuff like

   T opCast(T)() { ... }

and extend IFTI to work on casts as well.

-Lars

Brian <digitalmars brianguertin.com> writes:

 I think the most elegant solution -- and this is not my idea, it has
 been mentioned here several times before -- would be to be able to use
 templates for operator overloading. Then one could write stuff like
 
    T opCast(T)() { ... }


except templates arent virtual, i think the simplest method is to have 
the result as an argument.
void opCast(out int result) {}