D const design rationale

[Bill Baxter]

Sean Kelly wrote:
> Bill Baxter wrote:
>> Sean Kelly wrote:
>>> Derek Parnell wrote:
>>
>>>> A second issue I have is that by forcing 'const' to be explicitly 
>>>> coded in
>>>> function parameter lists, you are reducing the ability of the 
>>>> compiler to
>>>> help detect bugs.
>>>
>>> Isn't this necessary though?  Say the function declaration is 
>>> available to the compiler but the implementation is not.  The 
>>> compiler needs to know what kind of data can legally be passed as 
>>> parameters.
>>
>> I took that to mean he wanted to make const the default.
>>
>> I too am disappointed that the only rebuttal from Walter on const by 
>> default has been "some C++ guys I talked to thought it was weird".
> 
> Same here.  It's an elegant concept and I'd really like to give it a 
> try.  I think only experience could tell whether it's a practical solution.

Oh I forgot -- he did give two reasons, actually:
1) some c++ guys he talked to think it's weird.
2) didn't want to have to have a mutable keyword.
    (And in some other message later he said something about not wanting 
'mutable' in D because it left a bad taste in the mouth of some C++ guys.)

I still think anti-const keywords would be useful even *without* const 
by default.  So #2 seems kind of odd to me.  Seems to me it would be 
very handy to be able to say something like:
     mutable T foo(T)(T input) {
        mutable T mungeable;
        // munge the mungeable based in the input
        return mungeable
     }
Sure there's other ways to accomplish that, but that seems like a 
particularly clear way to express "same type as T but not const".
You could also make templates to strip it like they do in C++.  then you 
could have

     Mutable!(T) foo(T)(T input) {
     }

Either way I don't see any real insurmountable or even troublesome issue 
there with #2.

--bb