> You never gave any rationale reason on that.

Because I just like to have the control over what is passed by ref and what by value.
Maybe I want that a bigger struct is passed by value.
As long as I must denote parameters accordingly, in order that the compiler decide instead of me, this is no problem.
But if you have no control, because the compiler will decide for you, it would not be possible.
I'm considering a small example until evening.

On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
>> You never gave any rationale reason on that.
>
> Because I just like to have the control over what is passed by ref and what by value.

I'm sorry, but what you like is exactly the opposite of a rational example.

> Maybe I want that a bigger struct is passed by value.
> As long as I must denote parameters accordingly, in order that the compiler decide instead of me, this is no problem.
> But if you have no control, because the compiler will decide for you, it would not be possible.
> I'm considering a small example until evening.

On Tuesday, 12 March 2013 at 09:38:19 UTC, deadalnix wrote:
> On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
>>> You never gave any rationale reason on that.
>>
>> Because I just like to have the control over what is passed by ref and what by value.
>
> I'm sorry, but what you like is exactly the opposite of a rational example.

I'll always like to disabuse. So why do you think this is not a rational example? And what would a rational example for you?

On Tuesday, 12 March 2013 at 09:38:19 UTC, deadalnix wrote:
> On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
>>> You never gave any rationale reason on that.
>>
>> Because I just like to have the control over what is passed by ref and what by value.
>
> I'm sorry, but what you like is exactly the opposite of a rational example.
>

I've misunderstood you, ignore my post above please.
Well, I said "I like [...]" but I meant "It's important to controll what is passed by ref and what by value.". But I haven't yet an example for this. So maybe you're right. Whatever, our first concern should be to stimulate thinking of this and to call attention of Walter and/or Andrei.
Then we can still debated whether such parameters should be labeled as such, or not.

On Tuesday, 12 March 2013 at 11:24:43 UTC, Namespace wrote:
> On Tuesday, 12 March 2013 at 09:38:19 UTC, deadalnix wrote:
>> On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
>>>> You never gave any rationale reason on that.
>>>
>>> Because I just like to have the control over what is passed by ref and what by value.
>>
>> I'm sorry, but what you like is exactly the opposite of a rational example.
>
> I'll always like to disabuse. So why do you think this is not a rational example? And what would a rational example for you?

Let's consider the given example :

struct Foo {
    uint i;
    this(this) {
        writeln("foo");
    }
}

void bar(Foo f) {
    writeln("bar");
}

uint main() {
    Foo f;
    f.i = 42;
    bar(f);
    return f.i,
}

You think you pass by value ? In fact, if you let the optimizer do its job, you don't even have a function call. Thing gets rewriten this way :

uint main() {
    writeln("foo");
    writeln("bar");
    return 42;
}

You have no function call and no pass by value anymore. In fact, the only thing the current definition garantee it that you have the side effect of the postblit (ie, memory allocation, etc . . .), but nothing is said about having an actual function call or a pass by value.

If you think you control the code that way, you are living a delusional world, because the compiler rewrite everything under you. You are asking to keep that illusion in place by asking for an explicit syntax to allow the optimization to take place.

And note that this is very good thing as the code generated is much faster and the code much cleaner. If you had to specify optimisations, you'd get them wrong, you'd forget them, your code would be less reliable, slower and less readable.

On Tuesday, 12 March 2013 at 11:58:26 UTC, Namespace wrote:
> On Tuesday, 12 March 2013 at 09:38:19 UTC, deadalnix wrote:
>> On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
>>>> You never gave any rationale reason on that.
>>>
>>> Because I just like to have the control over what is passed by ref and what by value.
>>
>> I'm sorry, but what you like is exactly the opposite of a rational example.
>>
>
> I've misunderstood you, ignore my post above please.
> Well, I said "I like [...]" but I meant "It's important to controll what is passed by ref and what by value.". But I haven't yet an example for this. So maybe you're right. Whatever, our first concern should be to stimulate thinking of this and to call attention of Walter and/or Andrei.
> Then we can still debated whether such parameters should be labeled as such, or not.

Here is what I think. How the thing is actually passed don't matter. What does matter is that the semantic is know : ie that the program will behave in a known way.

As a consequence, if the compiler choose to pass by ref instead of passing by value as an optimization, it must do so only if it can prove that the resulting code will do the same thing.

> Here is what I think. How the thing is actually passed don't matter. What does matter is that the semantic is know : ie that the program will behave in a known way.
I agree.

> As a consequence, if the compiler choose to pass by ref instead of passing by value as an optimization, it must do so only if it can prove that the resulting code will do the same thing.
And how could it be proved? IMO with const (not mutable) scope (no escaping). What are your thoughts?

On Tuesday, 12 March 2013 at 15:19:14 UTC, Namespace wrote:
>> As a consequence, if the compiler choose to pass by ref instead of passing by value as an optimization, it must do so only if it can prove that the resulting code will do the same thing.
> And how could it be proved? IMO with const (not mutable) scope (no escaping). What are your thoughts?

To repeat myself :

The caller is free to call the ref version of the function unless
(rules evaluate in order) :
 - The argument is an rvalue (in such case, no postblit is
executed as well).
 - The argument is shared.
 - The argument's postblit in not pure (weakly).

The callee must create a local copy if (this is not verbatim from previous post as it has limitations as been pointed pointed) :
 - Mutate the struct or anything that *may* alias/be transitively reached through the struct.
 - Pass by ref/address taken to a non const/non weakly pure function (including method call) of the struct or anything that *may* alias/be transitively reached through the struct.

It does guarantee that visible result will be the same.

Am Tue, 12 Mar 2013 09:21:49 +0100
schrieb "Namespace" <rswhite4@googlemail.com>:

> I also think that we do not need 'inline' or 'register'. Nowadays, compilers can really assess the situation much better than we do.

Not to forget that ever since we have Intel, AMD and different
generations of complex CPUs (branch prediction,
prefetching, ...) in coexistence all the work you do to
optimize on your CPU (which improves over the compiler
generated code) might slow down the next CPU.
Maybe embedded developers disagree with my x86 centristic view,
though :)

-- 
Marco

> To repeat myself :
>
> The caller is free to call the ref version of the function unless
> (rules evaluate in order) :
>  - The argument is an rvalue (in such case, no postblit is
> executed as well).
>  - The argument is shared.
>  - The argument's postblit in not pure (weakly).
>
> The callee must create a local copy if (this is not verbatim from previous post as it has limitations as been pointed pointed) :
>  - Mutate the struct or anything that *may* alias/be transitively reached through the struct.
>  - Pass by ref/address taken to a non const/non weakly pure function (including method call) of the struct or anything that *may* alias/be transitively reached through the struct.
>
> It does guarantee that visible result will be the same.

Because I do not understand everything (due to my bad English) I would be glad to see one or maybe more examples where the compiler (according to your rules) change pass by value into pass by reference, and where not.

And the problem remains that we have to get the attention of Walter or Andrei.