Hello All !

From specs: "Since functions cannot be overloaded based on return value, there can be only one opCast per struct or class."

Why not to invent some syntax to allow multiple opCast ? It would be really
convinient and usefull, moreover, it seems to be better then inventing some
more magic methods such as toString.
To do it we can use something like

int opCast(int dummy);
char opCast(char dummy);

or

void opCast(out int res);
void opCast(out char res);

or

void opCast_r(out int res);
void opCast_r(out char res);


-- 
          Vladimir

Vladimir wrote:
> void opCast(out int res);
> void opCast(out char res);

This has been proposed before, by me and by others previous to me.  I still think its a really good idea, and hope you have more luck making it happen.

-- Chris Sauls

Chris Sauls wrote:
> Vladimir wrote:
>> void opCast(out int res);
>> void opCast(out char res);
> 
> This has been proposed before, by me and by others previous to me.  I still think its a really good idea, and hope you have more luck making it happen.

May be we can at least add this to wishlist ?

-- 
          Vladimir

I think this would be very useful.


Sean

Vladimir wrote:
> Hello All !
> 
> Why not to invent some syntax to allow multiple opCast ? It would be really
> convinient and usefull, moreover, it seems to be better then inventing some
> more magic methods such as toString.
> To do it we can use something like
> 
> int opCast(int dummy);
> char opCast(char dummy);
> 
> or
> 
> void opCast(out int res);
> void opCast(out char res);
> 
> or
> 
> void opCast_r(out int res);
> void opCast_r(out char res);

I support this.


-Benjamin

Vladimir wrote:
> Hello All !
> 
> From specs: "Since functions cannot be overloaded based on return value,
> there can be only one opCast per struct or class."
> 
> Why not to invent some syntax to allow multiple opCast ? It would be really
> convinient and usefull, moreover, it seems to be better then inventing some
> more magic methods such as toString.
> To do it we can use something like
> 
> int opCast(int dummy);
> char opCast(char dummy);
> 
> or
> 
> void opCast(out int res);
> void opCast(out char res);
> 
> or
> 
> void opCast_r(out int res);
> void opCast_r(out char res);
> 
> 
Didn't you say it wrong?  Don't you want:
void opCast (out resultType result, in  valueType value)
{...
   result = cast(resultType)value

}

This would allow conversion to be specified between any pair of types.  It can't be included in the type spec, because then types defined afterwards couldn't have any conversion defined to types defined earlier.  So two arguments are needed.

Note that because this is a cast operation, the _r form doesn't apply, unless I'm overlooking something.
Also note that this is NOT a function, but rather a procedure. It doesn't have a return value, it has an out parameter.  (This shouldn't make a difference, as a function with one out parameter is logically equivalent to a function, but the D syntax rules cause it to make an effective difference.)

The problem with this resolution is that the conversion becomes a procedure call...syntactically a different operation, and one that cannot be chained.  This would require special compiler logic.

Charles Hixson wrote:
<snip>
> Didn't you say it wrong?  Don't you want:
> void opCast (out resultType result, in  valueType value)
> {...
>    result = cast(resultType)value
> 
> }
> 
> This would allow conversion to be specified between any pair of types.  It can't be included in the type spec, because then types defined afterwards couldn't have any conversion defined to types defined earlier.  So two arguments are needed.

I'm not sure what you mean.

> Note that because this is a cast operation, the _r form doesn't apply, unless I'm overlooking something.

The _r form would be used to define conversions _to_ the type in which it is defined.  However, the OP's signature doesn't really make sense for this.  It would need to be something like

    static T opCast_r(int res);

> Also note that this is NOT a function, but rather a procedure. It doesn't have a return value, it has an out parameter.  (This shouldn't make a difference, as a function with one out parameter is logically equivalent to a function, but the D syntax rules cause it to make an effective difference.)
> 
> The problem with this resolution is that the conversion becomes a procedure call...syntactically a different operation, and one that cannot be chained.  This would require special compiler logic.

Obviously

    cast(int) qwert

would become something like this

    (function int(T t) { int i; t.opCast(i); return i; })(qwert)

and then chaining would be straightforward.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am Tue, 05 Apr 2005 14:23:42 +0100:
> Charles Hixson wrote:
><snip>
>> Didn't you say it wrong?  Don't you want:
>> void opCast (out resultType result, in  valueType value)
>> {...
>>    result = cast(resultType)value
>> 
>> }
>> 
>> This would allow conversion to be specified between any pair of types. It can't be included in the type spec, because then types defined afterwards couldn't have any conversion defined to types defined earlier.  So two arguments are needed.
>
> I'm not sure what you mean.

Just a guess:

# class A{ }
# class B{ }
#
# void opCast(out A a, in B b){}
#
# void opCast(out B b, in A a){}

Ofcourse the module names would have to be stripped from opCast's name.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCUpPJ3w+/yD4P9tIRAvhyAJ9CfG27o/IbHDnBki1IretbHJBltwCgvMUL
cr5pLXmiuNj8KoXeTm+VNLA=
=PVvg
-----END PGP SIGNATURE-----

Thomas Kuehne wrote:
> Stewart Gordon schrieb am Tue, 05 Apr 2005 14:23:42 +0100:
> 
>> Charles Hixson wrote:
<snip>
>>> This would allow conversion to be specified between any pair of
>>> types. It can't be included in the type spec, because then types
>>> defined afterwards couldn't have any conversion defined to types
>>> defined earlier.  So two arguments are needed.
>> 
>> I'm not sure what you mean.
> 
> Just a guess:
> 
> # class A{ }
> # class B{ }
> #
> # void opCast(out A a, in B b){}
> #
> # void opCast(out B b, in A a){}
<snip>

What I actually meant is: how does putting it in the type spec not make it possible to do this kind of thing?

Maybe Charles is stuck in the dark ages before forward references were invented?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am Tue, 05 Apr 2005 17:20:35 +0100:
> Thomas Kuehne wrote:
>> Stewart Gordon schrieb am Tue, 05 Apr 2005 14:23:42 +0100:
>> 
>>> Charles Hixson wrote:
><snip>
>>>> This would allow conversion to be specified between any pair of types. It can't be included in the type spec, because then types defined afterwards couldn't have any conversion defined to types defined earlier.  So two arguments are needed.
>>> 
>>> I'm not sure what you mean.
>> 
>> Just a guess:
>> 
>> # class A{ }
>> # class B{ }
>> #
>> # void opCast(out A a, in B b){}
>> #
>> # void opCast(out B b, in A a){}
><snip>
>
> What I actually meant is: how does putting it in the type spec not make it possible to do this kind of thing?

How do you declare opCast if the acutal implementation of the type is closed source? Either opCast is seperated from the type definition or opCast_receive has to be supported.

In addition how do you cast from a buildin type to a user defined one?
# long l;
# BigInt i = cast(BigInt)l;

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCUsJF3w+/yD4P9tIRAjeIAKCTkoEf0lqMeJeRRE/ZnPVrMOzEHwCgqFsE
ABVqTPU1FdGs5rQPvii1pek=
=m2mJ
-----END PGP SIGNATURE-----