• Vathix (5/5) Jul 08 2004 It being limited to one type and explicit... It would be easier to just ...
• Stewart Gordon (16/22) Jul 08 2004 There are lots of different kinds of types - primitives,
• Arcane Jill (17/22) Jul 08 2004 A number of suggestions have been made to fix this, including:
• Ben Hinkle (12/17) Jul 08 2004 The most common use I can think of is in templates like

"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

fine because it has rules that avoid C++'s problems with it (Section 13.4 of
ECMA-334).

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

 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.

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

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:




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.

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

 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