"Walter" <newshound@digitalmars.com> wrote in message news:d0o2qr$iif$2@digitaldaemon.com...
>
> "Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:d0mrip$2656$1@digitaldaemon.com...
>> cast(Foo)bar looks cool at first, but you can't do something that looks
> like a
>> cast on your own (e.g boost::lexical_cast looks like the other C++-cast).
> And
>> the C++-Casts are more powefull. If you defenitly know that an object has
> the
>> type you want to cast to, you can use a static cast, if you aren't sure,
> you can
>> use a dynamic cast. In D you allways have to use a dynamic cast, which is
> far
>> more expensive.
>
> You can do what you ask in D by first passing it through a 'void*' cast:
>
>    b = cast(B)cast(void*)a;

Well, if that doesn't prove that cast() is overly coarse, I don't know what does.

> which will do the same thing as C++:
>
>    b = static_cast<B*>(a);

This one is incontestably clearer.

"Walter" <newshound@digitalmars.com> wrote in message news:d0o3dn$j7m$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0nsvu$c1h$2@digitaldaemon.com...
>> Unless I'm stunningly misinformed - possible - this is complete
>> piffle.
>> In a recent conversation Walter informed me that cast() has pretty
>> much
>> sledge-hammer semantics. That was his main basis for not wanting
>> warnings about truncation, since it would incline people to overuse
>> casts, and casts can cast anything. I've not tested this out, yet,
>> but
>> I'm inclined to take it from the horse's mouth.
>
> I remember saying that to you, but when casting class references, it
> does
> behave like C++'s dynamic_cast.

Of course, I recognise that. But that's completely irrelevant. C's cast performs proper conversions when casting an int to a double. That does not detract from the legion flaws of C's cast.

> We weren't talking about class reference
> conversions at the time, so I did not think to bring it up.

Fair enough.

The problem with D's cast is exactly what prompted C++ to introduce its four built-in cast operators. There's nothing I can usefully add to their rationale, other than to say that C++'s template syntax and implicit instantiation makes a wonderfully powerful and extensible cast mechanism.

btw, I asked B.S. whether he'd planned it that way deliberately. With customary succinctness he said "it did occur to me". I consider this to be one of his many remarkable moments of genius in designing C++, and I heartily commend you to do the same, but better, for D.

Walter wrote:

> Oddly, I took the opposite approach. I dropped all use of 'const' that
> wasn't for declaration of constants. Instead, I treat all function
> parameters as read only unless documented otherwise. And in fact, rarely do
> functions need to change their parameters. It works, I simply have never had
> a problem with it.

And that shows in D, too : http://www.digitalmars.com/d/interface.html

> There are no const or volatile type modifiers in D.
> To declare a C function that uses those type modifiers,
> just drop those keywords from the declaration.

Copy-on-Write also implies that the arguments are readonly by default ?


But I can't think of any uses of "readonly" KW except for with char[],
so maybe it can be turned into some kind of array property instead ?

The last thing we want is an extra keyword to all regular parameters...
So maybe it would be better to have it in the array/slice information:

{ size_t length; void* data; byte flags; } // or something, pseudo

With one flag for "readonly", and one flag for "zero terminated" ?
(for optimizing toStringz, and similar functions that need to know)


Or something similarly different ?

--anders

In article <d0o2qq$iif$1@digitaldaemon.com>, Walter says...
>
>
>"Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:d0nj0k$bi$1@digitaldaemon.com...
>> I'm have made a habit of using 'const' all the time. I do that by
>intuition,
>> and are not very conscious about it anymore. I simply do not write code
>that
>> is not const-correct, and I haven't experienced such problems. But perhaps I'm not experienced enough to get myself into those situations you
>mention,
>> and stick to simpler code.
>
>Oddly, I took the opposite approach. I dropped all use of 'const' that wasn't for declaration of constants. Instead, I treat all function parameters as read only unless documented otherwise. And in fact, rarely do functions need to change their parameters. It works, I simply have never had a problem with it.

Interesting. That's basically the Fortran approach. In Fortran, for those who don't know, things are passed by reference and it is implicit you don't mess with the inputs.

When I code C++ I use const every now and just to get that little satisfaction of actually using it :-) But I don't do enough C++ to really depend on const or have it catch anything for me.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0o48n$k21$1@digitaldaemon.com...
> btw, I asked B.S. whether he'd planned it that way deliberately. With customary succinctness he said "it did occur to me". I consider this to be one of his many remarkable moments of genius in designing C++, and I heartily commend you to do the same, but better, for D.

Yes, B.S. did deliberately choose to use template syntax for it, and said so at the time. Just so you know!

"Walter" <newshound@digitalmars.com> wrote in message news:d0o6ca$m4g$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0o48n$k21$1@digitaldaemon.com...
>> btw, I asked B.S. whether he'd planned it that way deliberately. With
>> customary succinctness he said "it did occur to me". I consider this
>> to
>> be one of his many remarkable moments of genius in designing C++, and
>> I
>> heartily commend you to do the same, but better, for D.
>
> Yes, B.S. did deliberately choose to use template syntax for it, and
> said so
> at the time. Just so you know!

Ah! Then I'm the bearer of old news. Still, old's better than bad I suppose. ;)

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0o3ln$jho$2@digitaldaemon.com...
> > You can do what you ask in D by first passing it through a 'void*' cast:
> >
> >    b = cast(B)cast(void*)a;
>
> Well, if that doesn't prove that cast() is overly coarse, I don't know
> what does.
>
> > which will do the same thing as C++:
> >
> >    b = static_cast<B*>(a);
>
> This one is incontestably clearer.

It is? I remember when static_cast came out, I had to read the spec several times to figure out what it did. 'static' has no reliable meaning in C++. Suppose I propose:

    extern_cast<B*>(a);

for C++. What does it do?

"Walter" <newshound@digitalmars.com> wrote in message news:d0o6v7$mir$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0o3ln$jho$2@digitaldaemon.com...
>> > You can do what you ask in D by first passing it through a 'void*' cast:
>> >
>> >    b = cast(B)cast(void*)a;
>>
>> Well, if that doesn't prove that cast() is overly coarse, I don't
>> know
>> what does.
>>
>> > which will do the same thing as C++:
>> >
>> >    b = static_cast<B*>(a);
>>
>> This one is incontestably clearer.
>
> It is? I remember when static_cast came out, I had to read the spec
> several
> times to figure out what it did. 'static' has no reliable meaning in
> C++.
> Suppose I propose:
>
>    extern_cast<B*>(a);
>
> for C++. What does it do?

Fine. So what? Off the point.

I don't care a rats about what it's called, and I have a hard time believing that you think I do.

The point is that there are _different_ casts for doing _different_ things. Axiomatically, this reduces the likelihood of the execution of such operation from inadvertently doing another.

Am I being unreasonable to hope that you might address my point, or simply acknowledge that you'd rather not complicate the language/compiler?

I mean, come on. That double cast thing above is just bloody ridiculous. Anyone new dipping in and reading that post from the language designer is going to have their confidence factor drop to zero. Or am I wrong? Please explain

In article <d0o2ge$hf5$2@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Walter wrote:
>
>> A readonly property is completely orthogonal to a property requiring explicit initialization. Both are orthogonal to having const as a type modifiier. C++ mushes all these together into its notion of 'const'. I've been trying to separate them out in these discussions.
>
>I think I will call them "readonly" (const in C++), "final" (as in Java)
>for the property requiring explicit initialization (a.k.a "blank final")
>and "const" (like in D, meaning constant: instead of "#define PI 3.14",
>free for the compiler to literally replace and "inline" with the value?)

Not to put too fine a point on it but I'm not sure what you mean by "blank
final" here. Java's blank final is not the same as "final requiring explicit
initialization". In fact I think it's the opposite. In Java a blank final is
when a class field is declared "final" that is *not* given an initializer but is
provably assigned in every constructor.
See
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#35962

>>> > You can do what you ask in D by first passing it through a 'void*' cast:
>>> >
>>> >    b = cast(B)cast(void*)a;
[snip]
>>> > which will do the same thing as C++:
>>> >
>>> >    b = static_cast<B*>(a);
[snip]
>I mean, come on. That double cast thing above is just bloody ridiculous. Anyone new dipping in and reading that post from the language designer is going to have their confidence factor drop to zero. Or am I wrong? Please explain

Can we throw an itty-bitty template like the following into std somewhere? I'm half tempted to suggest putting it in std.c.stddef just because it's so C-like. Personally I don't think it'll get used much (Java gets along fine without one), but who knows...

// compile-time cast to a class T
template c_cast(T : Object) {
T c_cast(void* x) { return cast(T)x; }
}

// example
class A {}
class B:A {}
class C:A {}

int main() {
B b = new B;
C c = c_cast!(C)(b); // point gun at foot...
return 0;
}