Community

I think most would agree that const is more useful for some programs, but
more of an annoyance for others. Could the const be disabled by a compiler
option? If I disabled const when compiling a source file, I could still
rely on libraries that supported const, but I could write code as if there
were no const constraints.
-Craig

On 28/03/2008, Craig Black <cblack@ara.com> wrote:
> I think most would agree that const is more useful for some programs, but
> more of an annoyance for others. Could the const be disabled by a compiler
> option? If I disabled const when compiling a source file, I could still
> rely on libraries that supported const, but I could write code as if there
> were no const constraints.
I don't see how that would work. If I wrote
void f(C c)
{
/*code*/
}
void f(const(C) c)
{
/*different code*/
}
and you "disabled const", wouldn't that make the above code a compile
error (function defined twice)?

"Janice Caron" <caron800@googlemail.com> wrote in message
news:mailman.247.1206734444.2351.digitalmars-d@puremagic.com...
> On 28/03/2008, Craig Black <cblack@ara.com> wrote:
>> I think most would agree that const is more useful for some programs, but
>> more of an annoyance for others. Could the const be disabled by a
>> compiler
>> option? If I disabled const when compiling a source file, I could still
>> rely on libraries that supported const, but I could write code as if
>> there
>> were no const constraints.
>
> I don't see how that would work. If I wrote
>
> void f(C c)
> {
> /*code*/
> }
>
> void f(const(C) c)
> {
> /*different code*/
> }
>
> and you "disabled const", wouldn't that make the above code a compile
> error (function defined twice)?
No it would compile. Const syntax would be allowed, and the ABI
implications of const would be the same. Only it would ignore const
constraints.

"Craig Black" <cblack@ara.com> wrote in message
news:fsjh4h$172o$1@digitalmars.com...
>I think most would agree that const is more useful for some programs, but
>more of an annoyance for others. Could the const be disabled by a compiler
>option? If I disabled const when compiling a source file, I could still
>rely on libraries that supported const, but I could write code as if there
>were no const constraints.
>
> -Craig
I just don't see the advantage... as far as I'm aware you're never forced to
use const and const parameters to library methods for example shouldn't be
an issue as they should be implicitly cast without incident.
Even if you have a const object, say returned from a library method, and
require a non-const copy of it you can simply dup, and this seems like a
relatively rare-case.
Do you have any specific examples where const is significantly inconvenient
and as such worth being able to disable?

"Neil Vice" <psgdg@swiftdsl.com.au> wrote in message
news:fsnpjv$p7p$1@digitalmars.com...
>
> "Craig Black" <cblack@ara.com> wrote in message
> news:fsjh4h$172o$1@digitalmars.com...
>>I think most would agree that const is more useful for some programs, but
>>more of an annoyance for others. Could the const be disabled by a
>>compiler option? If I disabled const when compiling a source file, I
>>could still rely on libraries that supported const, but I could write code
>>as if there were no const constraints.
>>
>> -Craig
>
> I just don't see the advantage... as far as I'm aware you're never forced
> to use const and const parameters to library methods for example shouldn't
> be an issue as they should be implicitly cast without incident.
>
> Even if you have a const object, say returned from a library method, and
> require a non-const copy of it you can simply dup, and this seems like a
> relatively rare-case.
>
> Do you have any specific examples where const is significantly
> inconvenient and as such worth being able to disable?
No specific examples myself. It just seems that so many people are upset
about const, it might make them feel better if they can turn it off. D's
const system may very well be "mathematically sound". But the perception is
that it overcomplicates things. I personally am not really that attached to
this idea. Just thought it might help.

"Craig Black" wrote
>I think most would agree that const is more useful for some programs, but
>more of an annoyance for others. Could the const be disabled by a compiler
>option? If I disabled const when compiling a source file, I could still
>rely on libraries that supported const, but I could write code as if there
>were no const constraints.
The problem would be in code that depends on const being enforced, such as
for multi-threaded programs. It would be impossible to determine where
those would be without more annotation, and even then, you are relying on
authors of the code to properly annotate something that is not necessary in
the normal context. Think of how eager most coders are to document their
code rather than get it working :)
-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
news:fsqvqc$1cr4$1@digitalmars.com...
> "Craig Black" wrote
>>I think most would agree that const is more useful for some programs, but
>>more of an annoyance for others. Could the const be disabled by a
>>compiler option? If I disabled const when compiling a source file, I
>>could still rely on libraries that supported const, but I could write code
>>as if there were no const constraints.
>
> The problem would be in code that depends on const being enforced, such as
> for multi-threaded programs. It would be impossible to determine where
> those would be without more annotation, and even then, you are relying on
> authors of the code to properly annotate something that is not necessary
> in the normal context. Think of how eager most coders are to document
> their code rather than get it working :)
>
It would be easy enough to insert some sort of flag that would denote
whether a particular module is const correct or not, and have the
compiler/linker make some sort of guarantee for safety purposes.
Anyway, I don't really care enough about the idea to debate about the
details. It was just an idea.
-Craig