View mode: basic / threaded / horizontal-split · Log in · Help
March 28, 2008
Could const/invariant be optional?
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
March 28, 2008
Re: Could const/invariant be optional?
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)?
March 29, 2008
Re: Could const/invariant be optional?
"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.
March 30, 2008
Re: Could const/invariant be optional?
"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?
March 31, 2008
Re: Could const/invariant be optional?
"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.
March 31, 2008
Re: Could const/invariant be optional?
"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
March 31, 2008
Re: Could const/invariant be optional?
"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
Top | Discussion index | About this forum | D home