Question #1: I know that because you cannot overload functions based on the return type, they are limited.  But casting is more of a function with type as the parameter.  i.e.:

cast(Type)value;

I look at Type and value as the parameters to the cast.  Why doesn't opCast behave like:

int opCast(int)
{
  return myIntRepresentation;
}

float opCast(float)
{
  return myFloatRepresentation;
}

Question #2:  Is there a way to cast a basic type to a struct/class?  I can see uses for this, such as if you wanted to change an alias to a struct. e.g.:

before:
alias long myType;

myType convertToMyType(long x)
{
  return cast(myType)x;
}

after, I want to have methods on myType, etc:
struct myType
{
  long _value;
}

Now convertToMyType doesn't compile, and I have to go through and change all the casts that I previously used.   Is there a way to make it work with the current implementation, or does something need to be added?  What I'm thinking is something like a global function:

myType opCast(myType, long value)
{
  return myType(value);
}

Until these things work, there isn't a good way to make structs truly value types.

-Steve

Steven Schveighoffer Wrote:

> Question #1: I know that because you cannot overload functions based on the return type, they are limited.  But casting is more of a function with type as the parameter.  i.e.:
> 
> cast(Type)value;
> 
> I look at Type and value as the parameters to the cast.  Why doesn't opCast behave like:
> 
> int opCast(int)
> {
>   return myIntRepresentation;
> }
> 
> float opCast(float)
> {
>   return myFloatRepresentation;
> }
> 


Or maybe void opCast(out int) ?

Steven Schveighoffer wrote:
> Question #2:  Is there a way to cast a basic type to a struct/class?

D 2.0 will have an opImplicitCastFrom function, so you can write e.g.

struct myType {
    myType opImplicitCastFrom (long l) { ... }
}

This isn't implemented yet, but is planned.

Thanks,
Nathan Reed

"Nathan Reed" wrote
> Steven Schveighoffer wrote:
>> Question #2:  Is there a way to cast a basic type to a struct/class?
>
> D 2.0 will have an opImplicitCastFrom function, so you can write e.g.
>
> struct myType {
>     myType opImplicitCastFrom (long l) { ... }
> }
>
> This isn't implemented yet, but is planned.

Excellent!  I'm assuming since there is an argument, overloading is possible?  Also, the 'implicit' suggests that you can do something like:

long l;
myType x = l;

???

-Steve

Steven Schveighoffer Wrote:

> Excellent!  I'm assuming since there is an argument, overloading is possible?  Also, the 'implicit' suggests that you can do something like:
> 
> long l;
> myType x = l;
> 
> ???
> 
> -Steve

Yes, that will be possible. alter's presentation suggested there would be:

opImplicitCastTo
opImplicitCastFrom
opExplicitCastTo (what "opCast" does right now)
opExplicitCastFrom

All of which will be overloadable on different types (the slides had them overloadable on return type, but Walter mentioned that he might use out params instead). The opExplicitCasts were not mentioned in his slides, but he did say something that suggested they would be there.

"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:fbpmc1$9gb$1@digitalmars.com...
<snip>
> Yes, that will be possible. alter's presentation suggested there would be:
>
> opImplicitCastTo
> opImplicitCastFrom
> opExplicitCastTo (what "opCast" does right now)
> opExplicitCastFrom
>
> All of which will be overloadable on different types (the slides
> had them overloadable on return type, but Walter mentioned that he
> might use out params instead).  The opExplicitCasts were not
> mentioned in his slides, but he did say something that suggested
> they would be there.

So:
(a) programmer-defined implicit casts are going to be supported?  I thought this had been decided against because of the resulting sheer difficulty of determining what gets converted to what.
(b) it's going to be possible to define two different conversions from type X to type Y, one implicit and the other explicit???
(c) opImplicitCastTo and opExplicitCastTo are going to be special function names that allow return type overloading?

Please see my proposal:
http://www.digitalmars.com/d/archives/digitalmars/D/20540.html#N20712

It's similar to (c), but reuses the keyword 'cast' as a placeholder for a function name.

Stewart.