• "Craig Black" <cblack ara.com> Mar 28 2008
• "Janice Caron" <caron800 googlemail.com> Mar 28 2008
• "Craig Black" <craigblack2 cox.net> Mar 28 2008
• "Neil Vice" <psgdg swiftdsl.com.au> Mar 30 2008
• "Craig Black" <cblack ara.com> Mar 31 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Mar 31 2008
• "Craig Black" <cblack ara.com> Mar 31 2008

"Craig Black" <cblack ara.com> writes:

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 

"Janice Caron" <caron800 googlemail.com> writes:

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)?

"Craig Black" <craigblack2 cox.net> writes:

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

"Neil Vice" <psgdg swiftdsl.com.au> writes:

"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? 

"Craig Black" <cblack ara.com> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"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 

"Craig Black" <cblack ara.com> writes:

"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