Is there a reason not to support const qualifier for pointers/objects? With C code I've found this to be really useful in function parameters as it clearly tells the caller that the given parameter won't be modified.

Only reason I'm still using some #defined values in C code is that enum is signed and can't handle values larger than INT_MAX. This is really needed in code which accesses 32bit integer as a bitmask. How about adding support for unsigned enum type? Looks like currently only possibility is to declare "static const uint" variable which doesn't even seem to be optimized out of the binary..

Other than those I don't see a reason why I wouldn't use D one day.

Timo Sirainen wrote:
> How about adding support for unsigned enum type?

Already supported.

------------------------------
enum : uint {
    SOME_CONST = 4294967294,
    ANOTHER_ONE
}
------------------------------

-C. Sauls
-Invironz

"Timo Sirainen" <Timo_member@pathlink.com> wrote in message news:c60vnh$o2d$1@digitaldaemon.com...
> Is there a reason not to support const qualifier for pointers/objects?
With C
> code I've found this to be really useful in function parameters as it
clearly
> tells the caller that the given parameter won't be modified.

There were a couple of long threads about this issue. The case against const (which not everyone agrees with) is:

1) const types are not reliably constant, even in legal code
2) const as a type qualifier adds a lot of complexity to the language and
compiler
3) const adds a lot of unaesthetic 'noise' to declarations
4) in 15 years of using const, it has never found an actual bug (in my code,
anyway)

So, too much cost, too little benefit.

"Walter" <walter@digitalmars.com> wrote in message news:c61osu$2c17$1@digitaldaemon.com...
>
> "Timo Sirainen" <Timo_member@pathlink.com> wrote in message news:c60vnh$o2d$1@digitaldaemon.com...
> > Is there a reason not to support const qualifier for pointers/objects?
> With C
> > code I've found this to be really useful in function parameters as it
> clearly
> > tells the caller that the given parameter won't be modified.
>
> There were a couple of long threads about this issue. The case against
const
> (which not everyone agrees with) is:

You're not wrong!

> 1) const types are not reliably constant, even in legal code

(As I've said inumerable times) They don't need to be.

> 2) const as a type qualifier adds a lot of complexity to the language and compiler

I believe you on this point.

> 3) const adds a lot of unaesthetic 'noise' to declarations

Don't agree. You could say that about D's template syntax, or char[], or whatever. Any decent engineer just gets used to such things.


> 4) in 15 years of using const, it has never found an actual bug (in my
code,
> anyway)

Hugely disagree. In 13 years of using const, it has found thousands of potential bugs. Maybe you don't use the full power of const? (Incidentally, in your reviews of "Imperfect C++", I never heard a murmur from you regarding my strong use of const. Was this just to avoid a pointless debate, or were you unwilling to admit the power of my argument? <G>)

>
> So, too much cost, too little benefit.

Much cost, huge benefit. But I know you're never going to go for it, so once again I'll get my const rock out, and creep under.