On Sunday, 30 June 2013 at 09:24:28 UTC, Diggory wrote:
> [..]
>
> Also, the function needs to be strongly pure, not just weakly pure, otherwise the calling code could pass in both the const variable and a non-const reference to that variable. If the callee modifies the non-const reference it would see the changes to the const parameter which it shouldn't be able to do.

Good point. So, in order to elide postblit when a const variable is passed by value as a const argument, the function would not only need to be pure, but also all of its parameters would have to be either const or immutable.

Perhaps an interesting observation about this is that while in C++ const correctness literally never improves performance [1], in D (if these optimizations were implemented) const correctness could potentially increase performance considerably (if there are expensive postblits). Thus, functions should take arguments by const value rather than value, when the type of the parameter is either templated or has postblit.

[1] Except with constant folding or when the compiler can put const data to rommable memory and then share it with multiple instances of the same program.

On Sunday, 30 June 2013 at 10:21:12 UTC, TommiT wrote:
> Perhaps an interesting observation about this is that while in C++ const correctness literally never improves performance [1], in D (if these optimizations were implemented) const correctness could potentially increase performance considerably (if there are expensive postblits). Thus, functions should take arguments by const value rather than value, when the type of the parameter is either templated or has postblit.
>
> [1] Except with constant folding or when the compiler can put const data to rommable memory and then share it with multiple instances of the same program.

Precisely, although something that could improve performance even more would be escape analysis. In this example, if the compiler can prove that there are no global/parameter mutable references to a given variable then it will be able to apply the optimisation regardless of purity.

On Sunday, 30 June 2013 at 09:38:49 UTC, TommiT wrote:
>
> [..] So, in order to elide postblit when a const variable is passed by value as a const argument, the function would not only need to be pure, but also all of its parameters would have to be either const or immutable.

All along I've been saying "when const variable is passed to a function by const value...", but the postblit elision can be done also when a mutable variable is passed by const value (to a strongly pure function).

To take the full advantage of this optimization, a change in lambda function parameter type inference might be necessary, which sadly would be a breaking change:

struct S
{
    int get()
    {
        return 11;
    }

    int get() const
    {
        return 22;
    }
}

void main()
{
    S s;
    int n = (a) { return a.get(); }(s); // [1]
    writeln(n); // [2]
}

[1]: I think this lambda instantiates to something like:
int __fun(S a) { return a.get(); }
...but it'd be better if it first attempted to instantiate to:
int __fun(const S a) { return a.get(); }
...and resort to passing by mutable value only if the first attempt fails.

[2]: Currently prints 11, but would print 22 if this breaking change were made.

Yet one small observation: This optimization would mean that a lot of the use cases of "auto ref const MyType" parameters (the upcoming non-templated auto ref feature... although I don't know if that's the syntax for it) could be replaced by using "const MyType" parameters.

Or, if you look at it from the other side of the coin: if you always took function arguments by "auto ref const MyType", there wouldn't be any functions to apply this optimization for.

I posted an enhancement request for this:

http://d.puremagic.com/issues/show_bug.cgi?id=10527