On 06.10.2011 20:56, Steven Schveighoffer wrote:
On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
<[email protected]> 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.
