> >
> > We should have one cast for each kind of casting that can be done... and have cast if allowed on the current plateform vs defined exactly by the language...
> >
> > And I'd like to be able to add my owns...
>
> IMO we should just keep the simple cast (using a "cast(type, value)"
syntax
> to reduce the parameters) and have all the other casts as templates. If we do it this way we can keep the language clean of one hundred and one new keywords and the syntax of templates will certainly improve (just imagine dozens of developers frustrated with explicit instantiantion ;). Also templates are the standard way to provide generic code (i.e. you would be able to add your owns).
>
>

I have no problem with having other casts as template provide it is possible
to implement the desired cast... Often the compiler knows the information
while the programmer might or might not be able to knows it... I think that
in D we have more informations on type (like enum range) so we could more
easily define some of our cast... but some other might not be easily
possible
(is it possible to implement static_cast or dynamic_cast using only
templates
and existing cast by having specialisation for allowed and prohibited cases
and ensuring that prohibited cases does not compile?

So a minimum is needed to be able to do more... In C++, for example
it is hard to detect if a type is a class, an enum, a member pointer, a POD,
or to know if a class is abstract... without some support from the compiler.

In D, for example, we might want to know if a type is a typedef of another one. Also we might want to be able to check layout compatibity of 2 types:

struct S { double x; double y; double z };
alias double [3] Coord;

S s;
Coord c = layout_cast(s);    // I want to compiler to validate that the
layout
    is compatible (and as you can see, specifying the target might not be
    necessary (but implicit instanciation would be required).

In fact, implicit instanciation is required for any user type as we do not want to have to specify both the source and target type...

k = my_cast(TargetType, originalValue)

I would prefer something like:
.    class A {}
.    class B:A {void func(){}}
.    A b = new B;
.    B.cast(b).func();
Rather than having to write:
.    (cast(B) b).func();
Isn't the former easier to read?

Consider more complex code like the following:
.    ((CK) ((CA) list[i]).kid).func();
That becomes:
.    CK.cast(CA.cast(list[i]).kid).func();


Andrew Edwards:
> How about a cast property?
> double d = 3.14159;
> printf("%d", d.cast); // outputs 3

Matthew Wilson:
> Any chance of our getting away from the overused round braces in casts,
and
> adopt something less ambiguous, along the lines of the C++ casts? It seems like a retrograde step.

In article <bkq9th$17fn$1@digitaldaemon.com>, Dario says...
>.    B.cast(b).func();

Yes! finally something that makes sense!
We have been waiting for this for decades.

? b.castTo(B).func() ?

Ant

>>.    B.cast(b).func();

I hate this one. It looks like your doing something to a "B" object. But you aren't. You're doing something to a "b" object. This syntax is very deceptive.

>b.castTo(B).func()

This one, I like. A lot.

--Benji

In article <bkq9th$17fn$1@digitaldaemon.com>, Dario says...
>
>I would prefer something like:
>.    class A {}
>.    class B:A {void func(){}}
>.    A b = new B;
>.    B.cast(b).func();
>Rather than having to write:
>.    (cast(B) b).func();
>Isn't the former easier to read?
>
>Consider more complex code like the following:
>.    ((CK) ((CA) list[i]).kid).func();
>That becomes:
>.    CK.cast(CA.cast(list[i]).kid).func();


list[i].castTo(CA).kid.castTo(CK).funct
or list[i].cast(CA).kid.cast(CK).funct
or list[i].to(CA).kid.to(CK).funct

looks even better to me!

and
     list[i].castTo(MyClass*)
looks better then
     Class*.cast(list[i])
or
     (Class*).cast(list[i])

Ant

> In article <bkq9th$17fn$1@digitaldaemon.com>, Dario says...
>> I would prefer something like:
>>    class A {}
>>    class B:A {void func(){}}
>>    A b = new B;
>>    B.cast(b).func();

I stared that for a moment and thought that you surely made a typo there and actually meant to write:

b.cast(B).func();

Which kind of makes sense.

(similarly as Ant suggested:)

In article <bkqaoi$18hk$1@digitaldaemon.com>, Ant wrote:
>
> Yes! finally something that makes sense!
> We have been waiting for this for decades.
>
> ? b.castTo(B).func() ?

How about:

cast(B, b).func()

cast(B: b).func();

cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
                   // cast is not just any function

or even

cast(b, B).func();
cast(b to B).func();
cast(b as B).func();
cast(b -> B).func(); // too bad -> already has a meaning
cast(b: B).func();
cast(B b).func();

cast(B) b.func(); // Java style, huh?

(cast(B) b).func(); // What we have now. Cluttered.

But for what it's worth, D isn't trying to be Java, so well-written programs contain very few casts anyway and those that remain deserve to stand out. Right?

-Antti

> >>.    B.cast(b).func();
>
> I hate this one. It looks like your doing something to a "B" object. But you aren't. You're doing something to a "b" object. This syntax is very deceptive.
>
> >b.castTo(B).func()
>
> This one, I like. A lot.
>

Idem for me. I'd like the second syntax... and it is far better than the suggested on since it does not require too much parenthesis that we must look carefully...

In fact, we just have to look inside the () after the predefined castTo method to know what we are casting... and in complex expression, this is surely easier to read than prefix casting.

> > Yes! finally something that makes sense!
> > We have been waiting for this for decades.
> >
> > ? b.castTo(B).func() ?
>
> How about:
>
> cast(B, b).func()
>
> cast(B: b).func();
>
> cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
>                    // cast is not just any function
>
> or even
>
> cast(b, B).func();
> cast(b to B).func();
> cast(b as B).func();
> cast(b -> B).func(); // too bad -> already has a meaning
> cast(b: B).func();
> cast(B b).func();

In some case like casting the result of a function,
I like better

    f().castTo(double)

than

    cast(double, f())

I'm not sure about the last suggestion but I think that even
if it would be possible to uses a syntax without separator
it is better to have a separtator (and in my opinion it should be ,)
since if both the type and the expression are complex, it is
easier to see where one ends and the other start.

Also, I like using , as the separator as this is consistent with template...

>
> cast(B) b.func(); // Java style, huh?
>

With this syntac as in C++, it is hard to knows where the cast end if the expression is a bit complex and we need extra (). For example, if we want to cast function result...

> (cast(B) b).func(); // What we have now. Cluttered.
>
> But for what it's worth, D isn't trying to be Java, so well-written programs contain very few casts anyway and those that remain deserve to stand out. Right?
>
>

Cast should be easy to spot and should be easy to understand
without needing to count ()...

Also the selected syntax should be compatible with templates and should be extendable to user defined cast...

If the object.cast syntax is used, then we might want to be able to define our cast to a given type :

class C {
    operator castTo(D) { return ... }
    operator castTo(E) { return ... }

    template (T)
    operator castTo(T) { return member.castTo(T); }
}

OTHO, if we uses a syntax like cast(B, b), we should be able to define our owns casting functions that works the same way:

// Cast and if not possible returns default (just an example)
template (T, U)
T cast_or_default(U u)
{
    try {
        return cast(T) u;
    } catch(...) {
        return T.init;
    }
}

In article <slrnbn1eo0.dbp.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?= says...
>(similarly as Ant suggested:)
>
>In article <bkqaoi$18hk$1@digitaldaemon.com>, Ant wrote:
>>
>> Yes! finally something that makes sense!
>> We have been waiting for this for decades.
>>
>> ? b.castTo(B).func() ?
>
>How about:
>
>cast(B, b).func()

you mean:
cast(cast(list[i], B).kid), CK).func()
nahhh... same old thing...

list[i].castTo(CA).kid.castTo(CK).func()
is still better!

Ant

Nah, Ant's form is better.  Clearer.

b.cast(B).func();

Works even if B is a complicated typespec;  easy to parse;  easy to read. Self-documenting.

myObjectPtr[n].cast(myFoo*[])[i]->DoFooStuff("foo baby".cast(wchar[]));

This is good.  I like it better than the cast D has now.

DMD still hasn't gotten rid of C's typecast!  I thought the D spec doesn't support C typecasts?

Sean

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbn1eo0.dbp.jsykari@pulu.hut.fi...
> > In article <bkq9th$17fn$1@digitaldaemon.com>, Dario says...
> >> I would prefer something like:
> >>    class A {}
> >>    class B:A {void func(){}}
> >>    A b = new B;
> >>    B.cast(b).func();
>
> I stared that for a moment and thought that you surely made a typo there and actually meant to write:
>
> b.cast(B).func();
>
> Which kind of makes sense.
>
> (similarly as Ant suggested:)
>
> In article <bkqaoi$18hk$1@digitaldaemon.com>, Ant wrote:
> >
> > Yes! finally something that makes sense!
> > We have been waiting for this for decades.
> >
> > ? b.castTo(B).func() ?
>
> How about:
>
> cast(B, b).func()
>
> cast(B: b).func();
>
> cast(B; b).func(); // Syntax a bit similar to foreach(); emphasizes that
>                    // cast is not just any function
>
> or even
>
> cast(b, B).func();
> cast(b to B).func();
> cast(b as B).func();
> cast(b -> B).func(); // too bad -> already has a meaning
> cast(b: B).func();
> cast(B b).func();
>
> cast(B) b.func(); // Java style, huh?
>
> (cast(B) b).func(); // What we have now. Cluttered.
>
> But for what it's worth, D isn't trying to be Java, so well-written programs contain very few casts anyway and those that remain deserve to stand out. Right?
>
> -Antti
>