www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Current opCast: pointless?

reply "Vathix" <vathixSpamFix dprogramming.com> writes:
It being limited to one type and explicit... It would be easier to just add
members toType() like we already have toString(). If only opCast could be
implicit it would have some utility. C# has implicit casts that seem to work
fine because it has rules that avoid C++'s problems with it (Section 13.4 of
ECMA-334).
Jul 08 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Vathix wrote:

 It being limited to one type and explicit... It would be easier to just add
 members toType() like we already have toString().

There are lots of different kinds of types - primitives, programmer-defined types, pointers, arrays, functions, delegates ... how would we name the various toType methods?
 If only opCast could be
 implicit it would have some utility. C# has implicit casts that seem to work
 fine because it has rules that avoid C++'s problems with it (Section 13.4 of
 ECMA-334).

Being able to arbitrarily set up implicit casts would create complication in determining which version of a function is being called. The other day someone suggested having opCast take a dummy parameter: int opCast(int dummy) { ... } An alternative would be templates, like template opCast(T) { T opCast() { ... }} Of course, you would be using template specialisations almost exclusively. 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.
Jul 08 2004
prev sibling next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <ccj9er$172c$1 digitaldaemon.com>, Vathix says...
It being limited to one type and explicit... It would be easier to just add
members toType() like we already have toString(). If only opCast could be
implicit it would have some utility. C# has implicit casts that seem to work
fine because it has rules that avoid C++'s problems with it (Section 13.4 of
ECMA-334).

A number of suggestions have been made to fix this, including: # T opCast(T dummy); # void opCast(out T result); But so far no suggestion got past the suggestion stage. I don't believe /anyone/ uses opCast() as it currently exists. (Any takers to prove me wrong?). It _IS_ useless, and should be removed. I'd go so far as to call it a bug. (That is - I can certainly imagine some serious bugs arising from the current implementation). Obviously my first choice would be to replaced it with one of the above. But my second choice would be to remove it altogether, pending further thought. As things stand, it is /not/ better than nothing. (IMO). Walter is bug-fixing right now, so he may not get round to an improved version for a while. I'd definitely like to suggest that he remove it in the meantime. Arcane Jill PS. The whole implicit vs explicit argument is another story, probably best ignored until post 1.0.
Jul 08 2004
prev sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Vathix wrote:

 It being limited to one type and explicit... It would be easier to just
 add members toType() like we already have toString(). If only opCast could
 be implicit it would have some utility. C# has implicit casts that seem to
 work fine because it has rules that avoid C++'s problems with it (Section
 13.4 of ECMA-334).

The most common use I can think of is in templates like template foo(T) { void foo(T x) { int y = cast(int)x; ... so that T can be types like double, int, or any class which can be cast to int. Using toInt() would work as long as they were stand-alone functions (since double and int don't have methods) and everybody used the same naming scheme. That said I haven't used opCast yet. -Ben
Jul 08 2004