Ben Hinkle wrote:

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

As usual, my code example was clear and my "explanation" sucked. Thanks.

(see Matthew's const/readonly thread)

--anders

In article <d0o6v7$mir$1@digitaldaemon.com>, Walter says...
>
>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++.

Isn't 'static' the opposite of 'dynamic'? :-)

>Suppose I propose:
>
>    extern_cast<B*>(a);
>
>for C++. What does it do?

The opposite of 'static'. :-)

Ciao

>> simplified const handling (storage instead of type),
>
>As has been debated here many times <g>, const as a type modifier in C++ is so semantically weak it is fairly useless. (Many disagree.) C and C++ are the only languages I've ever heard of that use const as a type modifier. Java and C# show no signs of adopting it. The C++ community has not convinced the larger programmer community that const as a type modifier has a place.

Most languages don't have destructors. So the C++ community has not convinced
the larger programmer community that destructores have a place. But are
destructors bad just because of that?
I know you don't think so, otherwise D wouldn't have auto classes.

>> etc, and I guess I'd have more examples if I had been using C++ more...
>> And this makes C++ more "complete" in that you can do more things,
>> but is also makes a lot harder and complex - at least at the start ?
>
>I'd argue that C++ is less complete, since it relies so heavilly on STL to do things that are built in to most languages.

I know a lot of languages that have built in linked lists (Lisp, SML, O'Caml, Haskell, Clean, ... to name just a few popular languages). D does not. Why?

>Doing a general purpose
>foreach with C++ is fiendishly difficult. It's for free in D.

OK, C++ is still not perfect. But imagine C++ with Lisp-like macros. You could do a foreach easily, without having it built in. Or imagine C++ with a Sather-like iteration model. You wouldn't need a foreach loop any more.

A foreach loop isn't realy a killer-feature that no other language knows about.

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:d0psuo$2gc6$1@digitaldaemon.com...
> >> simplified const handling (storage instead of type),
> >
> >As has been debated here many times <g>, const as a type modifier in C++
is
> >so semantically weak it is fairly useless. (Many disagree.) C and C++ are the only languages I've ever heard of that use const as a type modifier. Java and C# show no signs of adopting it. The C++ community has not convinced the larger programmer community that const as a type modifier
has
> >a place.
>
> Most languages don't have destructors. So the C++ community has not
convinced
> the larger programmer community that destructores have a place. But are
> destructors bad just because of that?
> I know you don't think so, otherwise D wouldn't have auto classes.

Of course. It should be of strong interest to any language designer what other language designers do. Both Java and C# came from C++. What C++ features did they pick, what did they leave out, and most importantly, why? I believe many of the choices they made are excellent, and many are mistakes. It's important that I be able to justify the decisions for D, and if it diverges from what other C++ based language designers chose, I think the bar is at least a little higher for justifying it.

> >> etc, and I guess I'd have more examples if I had been using C++ more...
> >> And this makes C++ more "complete" in that you can do more things,
> >> but is also makes a lot harder and complex - at least at the start ?
> >
> >I'd argue that C++ is less complete, since it relies so heavilly on STL
to
> >do things that are built in to most languages.
>
> I know a lot of languages that have built in linked lists (Lisp, SML,
O'Caml,
> Haskell, Clean, ... to name just a few popular languages). D does not.
Why?

Because the UDT facilities in D are good enough that it's trivial to do a linked list.

> >Doing a general purpose
> >foreach with C++ is fiendishly difficult. It's for free in D.
> OK, C++ is still not perfect. But imagine C++ with Lisp-like macros. You
could
> do a foreach easily, without having it built in. Or imagine C++ with a Sather-like iteration model. You wouldn't need a foreach loop any more. A foreach loop isn't realy a killer-feature that no other language knows
about.

I agree that foreach is hardly unique to D. It's not a killer feature, either. It's not, by itself, a reason for people to switch from C++ to D.

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:d0p053$1jav$1@digitaldaemon.com...
> In article <d0o6v7$mir$1@digitaldaemon.com>, Walter says...
> >
> >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++.
>
> Isn't 'static' the opposite of 'dynamic'? :-)
>
> >Suppose I propose:
> >
> >    extern_cast<B*>(a);
> >
> >for C++. What does it do?
>
> The opposite of 'static'. :-)

Yup <g>. The point being that it's clear what it does only after carefully reading the documentation.

The double cast way of doing static casts in D is an idiom. There are idioms in D just like there are well-known idioms in C++. I suggest that the double cast idiom will become one of those well recognized ones and it's meaning will be clear because people will be used to seeing it and using it.

"Walter" <newshound@digitalmars.com> wrote in message news:d0q1vg$2m2t$1@digitaldaemon.com...
>
> "Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:d0p053$1jav$1@digitaldaemon.com...
>> In article <d0o6v7$mir$1@digitaldaemon.com>, Walter says...
>> >
>> >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++.
>>
>> Isn't 'static' the opposite of 'dynamic'? :-)
>>
>> >Suppose I propose:
>> >
>> >    extern_cast<B*>(a);
>> >
>> >for C++. What does it do?
>>
>> The opposite of 'static'. :-)
>
> Yup <g>. The point being that it's clear what it does only after
> carefully
> reading the documentation.
>
> The double cast way of doing static casts in D is an idiom. There are
> idioms
> in D just like there are well-known idioms in C++. I suggest that the
> double
> cast idiom will become one of those well recognized ones and it's
> meaning
> will be clear because people will be used to seeing it and using it.

Sorry to get all unprofessional, but when I read you saying things like this I wonder whether the world is made of chocolate, and Homer's eaten out my brain.

That double cast is a freakish bit of code, that will be fantastic fodder for D-etractors. I'm just stunned that you think that it's reasonable, in a language with all the intentions D makes, to propose such hacks, instead of addressing real needs within the (pre-1.0) language itself.

Sure, maybe it's me. I could be cracked, but I really think not (at least in this case). I'll attempt some rationalisation:

D's design is predicated on the fact that pointers are dangerous, and, despite their acknowledged power (and facilitation of efficiency) cause problems for the (un)wary in C and C++. While D permits use of pointers, goto, etc. etc. for interfacing to C and such things - a good thing, and an advantage over nannying languaJes - it should be possible to avoid them and still be able to practice D in a powerful, full-featured sophisticated way. Now I may be editorialising somewhat, but I'm pretty sure I've read those arguments from your posts over the years, albeit in fragmented form perhaps. Please correct me if this misrepresents things.

Now we come to casting. There are all kinds of casting, whether they bear distinct names or have distinct language constructs or not. Integral truncation. Integral promotion. Type conversion (/subversion). OO hierarchy navigation.  etc. etc.

Users from other languages in which these issues have already been sensibly addressed will naturally seek to avoid the too-coarse-grained cast() operator. You've recognised that, and demonstrated a technique whereby they might do so. But what you're telling them is that, to do so, they must use pointers in a language that specifically eschews pointers.

This is inconsistent, and gives the impression that the language is hacked together. If I'm wrong to draw that conclusion, I'm very interested to have it explained to me.

Now, why do we have access to only a single too-coarse-grained cast()? Because you, personally, do not appreciate the purpose (or perhaps the implementation) of different cast operators. This may be because you (as I'm pretty sure you've admitted) tend not to use them. Or maybe you tend not to use them because you don't appreciate them. Chicken or egg. Impossible to tell. (Again, please correct me if I'm misrepresenting you.)

I have to say that I can draw no other conclusion than that:
    a. you do not like/appreciate cast richness, therefore
    b. you don't (much?) use these casts, therefore
    c. you do not think they should be in D, therefore
    d. you have come up with a farcical cast hack, using things that are
expressively avoided/avoidable in 'normal' D. And you've called it an
idiom!!

It's just bonkers.

I put it to everyone who's managed to get to stick with the rant to this point to select which of the following is more discoverable, maintainable, amenable to automated code searching tools, indicative of considered design, attractive, etc.:

    b = cast(B)cast(void*)a;

    b = type_cast(B)(a);

(Note: type_cast is just a name I conjured for the example. Naturally we'd go through a collegial process for coming up with good and sensible names for any/all specific cast operators.)

I have to agree that the 'idiom' described did have me chuckling heartily, for many of the reasons you describe. In particular, if this would be used often enough to become an "idiom", then why the heck wouldn't the language clean up the syntax?

Perhaps it should be called one of the following?

>    b = castigate(B) a;
>
>    b = castrate(B) a;

:-}

It does seem jolly silly for it to remain as "cast(B) cast(void*) a" instead.
Egad!




In article <d0qksf$9im$1@digitaldaemon.com>, Matthew says...
>
>
>"Walter" <newshound@digitalmars.com> wrote in message news:d0q1vg$2m2t$1@digitaldaemon.com...
>>
>> "Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:d0p053$1jav$1@digitaldaemon.com...
>>> In article <d0o6v7$mir$1@digitaldaemon.com>, Walter says...
>>> >
>>> >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++.
>>>
>>> Isn't 'static' the opposite of 'dynamic'? :-)
>>>
>>> >Suppose I propose:
>>> >
>>> >    extern_cast<B*>(a);
>>> >
>>> >for C++. What does it do?
>>>
>>> The opposite of 'static'. :-)
>>
>> Yup <g>. The point being that it's clear what it does only after
>> carefully
>> reading the documentation.
>>
>> The double cast way of doing static casts in D is an idiom. There are
>> idioms
>> in D just like there are well-known idioms in C++. I suggest that the
>> double
>> cast idiom will become one of those well recognized ones and it's
>> meaning
>> will be clear because people will be used to seeing it and using it.
>
>Sorry to get all unprofessional, but when I read you saying things like this I wonder whether the world is made of chocolate, and Homer's eaten out my brain.
>
>That double cast is a freakish bit of code, that will be fantastic fodder for D-etractors. I'm just stunned that you think that it's reasonable, in a language with all the intentions D makes, to propose such hacks, instead of addressing real needs within the (pre-1.0) language itself.
>
>Sure, maybe it's me. I could be cracked, but I really think not (at least in this case). I'll attempt some rationalisation:
>
>D's design is predicated on the fact that pointers are dangerous, and, despite their acknowledged power (and facilitation of efficiency) cause problems for the (un)wary in C and C++. While D permits use of pointers, goto, etc. etc. for interfacing to C and such things - a good thing, and an advantage over nannying languaJes - it should be possible to avoid them and still be able to practice D in a powerful, full-featured sophisticated way. Now I may be editorialising somewhat, but I'm pretty sure I've read those arguments from your posts over the years, albeit in fragmented form perhaps. Please correct me if this misrepresents things.
>
>Now we come to casting. There are all kinds of casting, whether they bear distinct names or have distinct language constructs or not. Integral truncation. Integral promotion. Type conversion (/subversion). OO hierarchy navigation.  etc. etc.
>
>Users from other languages in which these issues have already been sensibly addressed will naturally seek to avoid the too-coarse-grained cast() operator. You've recognised that, and demonstrated a technique whereby they might do so. But what you're telling them is that, to do so, they must use pointers in a language that specifically eschews pointers.
>
>This is inconsistent, and gives the impression that the language is hacked together. If I'm wrong to draw that conclusion, I'm very interested to have it explained to me.
>
>Now, why do we have access to only a single too-coarse-grained cast()? Because you, personally, do not appreciate the purpose (or perhaps the implementation) of different cast operators. This may be because you (as I'm pretty sure you've admitted) tend not to use them. Or maybe you tend not to use them because you don't appreciate them. Chicken or egg. Impossible to tell. (Again, please correct me if I'm misrepresenting you.)
>
>I have to say that I can draw no other conclusion than that:
>    a. you do not like/appreciate cast richness, therefore
>    b. you don't (much?) use these casts, therefore
>    c. you do not think they should be in D, therefore
>    d. you have come up with a farcical cast hack, using things that are
>expressively avoided/avoidable in 'normal' D. And you've called it an idiom!!
>
>It's just bonkers.
>
>I put it to everyone who's managed to get to stick with the rant to this point to select which of the following is more discoverable, maintainable, amenable to automated code searching tools, indicative of considered design, attractive, etc.:
>
>    b = cast(B)cast(void*)a;
>
>    b = type_cast(B)(a);
>
>(Note: type_cast is just a name I conjured for the example. Naturally we'd go through a collegial process for coming up with good and sensible names for any/all specific cast operators.)
>
>
>

In article <d0qp27$e54$1@digitaldaemon.com>, Kris says...
>
>It does seem jolly silly for it to remain as "cast(B) cast(void*) a" instead.
>Egad!

Well, having rolled my own casting operator myself, I'd like to add my $0.02 to the pot.

I can easily forsee a templatized wrapper around the const-cast idiom:

> static_cast!(Foo)(bar);

Which is really the ghost of language past.  Let's not do this, please.  I for one would rather see the typical kinds of casts enshrined in the language itself:

> static_cast(Foo) bar;

Along with all of its friends:

> cast(Foo) bar;
> dynamic_cast(Foo) bar; // same as vanilla cast()
> static_cast(Foo) bar;
> const_cast(Foo) bar; // depending on the outcome of the 'const saga'.
> extern_cast(Foo) bar; // classname based cast rather than typeid based.


Now not having these in the language is no real loss, thanks to the (incomplete) ABI.  However, use of such casts is frequent enough that adding them could only help us write cleaner (varargs come to mind) code.

Also, I'll add that the template system is inadequate to make a completely water-tight cast operator, so something needs to be done one way or the other.

- EricAnderton at yahoo

In article <d0r40c$o40$1@digitaldaemon.com>, pragma says...
>
>In article <d0qp27$e54$1@digitaldaemon.com>, Kris says...
>>
>>It does seem jolly silly for it to remain as "cast(B) cast(void*) a" instead.
>>Egad!
>
>Well, having rolled my own casting operator myself, I'd like to add my $0.02 to the pot.
>
>I can easily forsee a templatized wrapper around the const-cast idiom:
>
>> static_cast!(Foo)(bar);
>
>Which is really the ghost of language past.  Let's not do this, please.  I for one would rather see the typical kinds of casts enshrined in the language itself:
>
>> static_cast(Foo) bar;
>
>Along with all of its friends:
>
>> cast(Foo) bar;
>> dynamic_cast(Foo) bar; // same as vanilla cast()
>> static_cast(Foo) bar;
>> const_cast(Foo) bar; // depending on the outcome of the 'const saga'.
>> extern_cast(Foo) bar; // classname based cast rather than typeid based.
>
>
>Now not having these in the language is no real loss, thanks to the (incomplete) ABI.  However, use of such casts is frequent enough that adding them could only help us write cleaner (varargs come to mind) code.
>
>Also, I'll add that the template system is inadequate to make a completely water-tight cast operator, so something needs to be done one way or the other.
>
>- EricAnderton at yahoo

ack - I really hope D doesn't end up with a bazillion (or even, say, three)casting options. Casting is so rare and the performance hit of a dynamic cast vs static cast hasn't ever been a problem in my Java coding experience that it would be a pity to burden future D coder with all the esoteric casts. Why bother? Casting is evil - so why obsess over it.

One benefit of the double cast is it makes it explicit what is actually happening. Say I have an int x that I want to cast to an object reference. I actually prefer cast(Object)cast(void*)x since it spells out the process of turning an int into a reference - not that I encourage that sort of thing :-)

Ben Hinkle wrote:
<snip>
> ack - I really hope D doesn't end up with a bazillion (or even, say,
> three)casting options. Casting is so rare and the performance hit of a dynamic
> cast vs static cast hasn't ever been a problem in my Java coding experience that
> it would be a pity to burden future D coder with all the esoteric casts. Why
> bother? Casting is evil - so why obsess over it.


I don't think anyone is obsessing, Ben. There's only been a couple of posts on this particular angle, compared to what must be /hundreds/ over '$' :-)

I can't imagine anyone would claim that casting is the "right" way, but Walter did bring it up in terms of an 'idiom' ... for that, it needs to be applied to a certain degree (as opposed to never).


> One benefit of the double cast is it makes it explicit what is actually
> happening. Say I have an int x that I want to cast to an object reference. I
> actually prefer cast(Object)cast(void*)x since it spells out the process of
> turning an int into a reference - not that I encourage that sort of thing :-)


Again, I can't imagine you'd get an argument here. But this is not the case in question. What you're noting here is a gross violation ~ unless I misread you?

Just for the record: I encourage people to avoid casting, since it tends to hide issues that the compiler might otherwise catch, and it can make maintenance and/or refactoring that much more difficult. However, if Walter expects developers will use static-casts, then that usage should be explicitly supported ~ if nothing else, it will isolate those instances from the 'gross violation' cases you identified above.

I don't suppose anyone thought 'castigate' was an appropriate term? No? Oh well :-)