March 28, 2008
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
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
"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
"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
"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
"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
"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