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

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.

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.

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