about const and immutable (again)

[Steven Schveighoffer]

On Mon, 10 Oct 2011 21:29:08 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 10/10/11 5:55 PM, Don wrote:
>> On 06.10.2011 20:56, Steven Schveighoffer wrote:
>>> On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
>>> <gor.f.gyolchanyan at gmail.com> wrote:
>>>
>>>> I see. Thanks for the detailed answer.
>>>
>>> I should clarify one point, I realized I am somewhat inaccurate on the
>>> reason the type is set to immutable(dchar). In fact, nobody actually
>>> wrote the immutable(dchar) function, it's just that the element type is
>>> immutable(dchar). However, the reasons why someone would want to create
>>> a function that takes an immutable(dchar) function are as I stated --  
>>> so
>>> you don't accidentally change the value.
>>
>> That seems like the discussed-and-discarded 'final' storage class for
>> parameters. But this is worse. It has an *enormous* cost.
>
> Walter and I have agreed for a long time that upon function calls with  
> by-value passing, there should be some simple transforms done:
>
> 1. If a parameter has no indirections, qual(T) becomes T.
>
> 2. qual(T[]) becomes qual(T)[].
>
> 3. qual(T*) becomes qual(T)*.
>
> This would improve many aspects of the language. Walter never got to  
> implementing it, but I'm bringing this up in case one of the wonderful  
> compiler contributors would want to take it up. Again, I have reasons to  
> believe Walter would approve of the change.

I agree, this would help tremendously. Would this apply to function  
pointers/delegates as well?  For example:

void foo(const(int) i) {}

assert(is(typeof(&foo) == void function(int));

I would prefer it not be this way, and rather start defining some implicit  
delegate/function casting.  I think D really needs this, not just in the  
area of const.

-Steve