C++ has a type of function which is used in implicit conversions: operator <type> (). By using this type of function, one type of object can be implicitly converted to another type of object. Does D have something similar (which I can't find in the docs) ?

If not, does Walter plan to do it ? is there an alternative ? For me, it is quite useful, as I can define value structs which are implicitly converted to something when as that something. For example, an RGB struct is implicitly converted to int when used as int, producing a pixel value for the current graphics context.

Achilleas Margaritis wrote:

>C++ has a type of function which is used in implicit conversions: operator
><type> (). By using this type of function, one type of object can be
>implicitly converted to another type of object. Does D have something
>similar (which I can't find in the docs) ?
>
>  
>
No there is no such thing in D.

>If not, does Walter plan to do it ? is there an alternative ? 
>
I doubt Walter will implement anything like this as it goes against his design principals.  That's why D doesn't have a copy-constructor.

>For me, it is
>quite useful, as I can define value structs which are implicitly converted
>to something when as that something. For example, an RGB struct is
>implicitly converted to int when used as int, producing a pixel value for
>the current graphics context.
>
Parhaps you could just wrap the graphics context up (pseudo): ie

void putPixel(RGB c, int x, int y) { putPixel((int)c, x, y);}

void putPixel(int c, int x, int y)
{
    dc[x+y*height] = c;
}


Or write a generic conversion function like so:

template covT(T1, T2)
{
   T2 cov(T1 t) { return *(cast(T2*) &t); }
}

struct RGBA
{
       byte R,G,B,A;
}

alias covT!(int, RGBA).cov cov;
alias covT!(RGBA, int).cov cov;

void func(int c)
{
  }

int main ( char [] [] args )
{
   RGBA c;

   int ic = cov(c);
   RGBA irgba = cov(ic);
     func(cov(c));

   return 1;
}

-- 
-Anderson: http://badmama.com.au/~anderson/

<snip>
>C++ has a type of function which is used in implicit conversions: operator <type> (). By using this type of function, one type of object can be
</snip>

Ew. Implicit conversions (casts) should only be allowed between like types (e.g. among integer types, among real types, etc.) and of course only when no data is lost. As such I am against implicit conversion to boolean, which I feel is most evil.

You should consider a property, like  RGB.intValue  or something, even make it a setter as well as a getter.

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:c6p61u$1c5j$1@digitaldaemon.com...
> C++ has a type of function which is used in implicit conversions: operator <type> (). By using this type of function, one type of object can be implicitly converted to another type of object. Does D have something similar (which I can't find in the docs) ?
>
> If not, does Walter plan to do it ? is there an alternative ? For me, it is quite useful, as I can define value structs which are implicitly converted to something when as that something. For example, an RGB struct is implicitly converted to int when used as int, producing a pixel value for the current graphics context.

D's not going to have them. There are other approaches. How about some Shims (http://www.cuj.com/documents/s=8681/cuj0308wilson/), for example? You might not like it because it's a new buzzword, tho ... ;)

J Anderson wrote:

> Achilleas Margaritis wrote:
<snip>
>> For me, it is quite useful, as I can define value structs which are implicitly converted to something when as that something. For example, an RGB struct is
>> implicitly converted to int when used as int, producing a pixel value for
>> the current graphics context.
>
> Parhaps you could just wrap the graphics context up (pseudo): ie
<snip>

I tend to use unions for this kind of stuff.  e.g.

	union RGBA {
		struct { byte r, g, b, a; }
		int value;
	}

Then you only need to define each function once.  You can add an opCall to the union to make it easy to construct.  See
http://www.digitalmars.com/drn-bin/wwwnews?D/25334

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.