• Steven Schveighoffer (39/39) Sep 06 2007 Question #1: I know that because you cannot overload functions based on ...
• Funog (2/21) Sep 06 2007 Or maybe void opCast(out int) ?
• Nathan Reed (8/9) Sep 06 2007 D 2.0 will have an opImplicitCastFrom function, so you can write e.g.
• Steven Schveighoffer (7/14) Sep 06 2007 Excellent! I'm assuming since there is an argument, overloading is
• Robert Fraser (7/16) Sep 06 2007 Yes, that will be possible. alter's presentation suggested there would b...
• Stewart Gordon (16/26) Sep 10 2007 "Robert Fraser" wrote in message

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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;
}


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 

Funog <funog ifrance.com> writes:

Steven Schveighoffer Wrote:


 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) ?

Nathan Reed <nathaniel.reed gmail.com> writes:

Steven Schveighoffer wrote:


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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Nathan Reed" wrote
 Steven Schveighoffer wrote:


 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 

Robert Fraser <fraserofthenight gmail.com> writes:

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.

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"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.