about const and immutable (again)

[Don]

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.
Making immutable(dchar) parameters different from dchar causes *massive* 
code bloat. Every n parameter template gets 3^^n copies!! And that has a 
speed cost (use of code cache, branch prediction, etc).
You can see the 2^^n explosion in action in std.writefln; executables 
bloat up enormously.
But it gets worse -- it makes it harder to write templates correctly.
For example, if the signature is:
bool foo(X)(X a, X b) if (is(X : double)) {...}
then foo doesn't accept (double, const(double)).

And it's entirely unnecessary. The question of whether a function can 
modify its value parameters is an internal implementation detail of that 
function. It has no consequences for the caller, so it shouldn't be 
externally visible. Nobody else needs to know or care.

We need to reconsider this. I think it's the way it is by accident; I 
don't remember any discussion about it.

> Still no excuse that delegates cannot be implicitly cast to compatible
> versions.