On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
> On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis wrote:
>> Which does not generally work in D. It can in some cases, but const is so restrictive in D that you simply cannot use it just because you don't intend to mutate a variable. Too many types won't work with const, and many types _can't_ work with const. const has its uses, but you have to be careful with it, and in the general case, that means that you can't put it on function parameters just to indicate that the function argument is not going to mutated.
>>
>> - Jonathan M Davis
>
> Thus the solution cannot require const.
>
> auto is worse because, if you later decide you need to add a template parameter then the meaning is changed and you get a _hidden_ performance issue.

And how does it introduce a hidden performance issue. You'd end up with some template bloat, but that's it, and that's just going to increase the memory footprint of your program slightly, which isn't generally going to be a performance issue. It's just going to make your program slightly larger.

- Jonathan M Davis

On Tuesday, 23 June 2015 at 12:45:25 UTC, kink wrote:
> On Tuesday, 23 June 2015 at 09:57:26 UTC, Marc Schütz wrote:
>> To guarantee this from the caller's POV, the callee must be pure and the parameters must be known not to alias each other.
>
> This is obviously true. Rvalues aren't affected as they cannot alias another parameter by definition.

You're right, I didn't think of that! They are not _transitively_ unique, but there can indeed be no other references to the rvalues themselves. So for rvalues, const is enough. Nice :-)

> Lvalues are if passed by ref and the same instance is accessible by mutable ref from another parameter or global. But as shown by your example, that danger is always there. The proposed `in` semantics make it less obvious, that's true, but I still think it'd be worth it, as these aliasing bugs are a pain to track down, but in my experience extremely rare.

On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis wrote:
> On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
>> On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis wrote:
>>> [...]
>>
>> Thus the solution cannot require const.
>>
>> auto is worse because, if you later decide you need to add a template parameter then the meaning is changed and you get a _hidden_ performance issue.
>
> And how does it introduce a hidden performance issue. You'd end up with some template bloat, but that's it, and that's just going to increase the memory footprint of your program slightly, which isn't generally going to be a performance issue. It's just going to make your program slightly larger.
>
> - Jonathan M Davis

instruction cache misses can really hurt

On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions.

You would be losing the optimization of passing primitive types by value, wouldn't you?

  Bit

On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote:
> On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions.
>
> You would be losing the optimization of passing primitive types by value, wouldn't you?

Not if you keep the current `auto ref` template syntax AND introduce another syntax `scope ref` for non-escapable references also accepting rvalues.

On Tue, 23 Jun 2015 14:33:49 -0400, kinke <noone@nowhere.com> wrote:

> On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote:
>> On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:
>>
>>> There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions.
>>
>> You would be losing the optimization of passing primitive types by value, wouldn't you?
>
> Not if you keep the current `auto ref` template syntax AND introduce another syntax `scope ref` for non-escapable references also accepting rvalues.

I don't think 'scope ref' is on the table at this point(although I do believe it should be).

And I still think Timon's statement is untrue. There is a reason, which is that the new auto ref syntax forces reference parameters for all types(even primitives), where the old template approach does not.

  Bit

On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
> And I still think Timon's statement is untrue. There is a reason, which is that the new auto ref syntax forces reference parameters for all types(even primitives), where the old template approach does not.

Timon suggested using another syntax/name for the new refs, as one couldn't use them in templates [and the different `auto ref` behavior is just prone to confuse beginners, my 2 cents]. One reason for preferring `scope ref` over `auto ref` in templates would be situations where code bloat is more important than runtime performance, another reason the fact that `in ref` is more convenient than `const auto ref`. ;)

On Tuesday, 23 June 2015 at 17:05:41 UTC, John Colvin wrote:
> On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis wrote:
>> On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
>>> On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis wrote:
>>>> [...]
>>>
>>> Thus the solution cannot require const.
>>>
>>> auto is worse because, if you later decide you need to add a template parameter then the meaning is changed and you get a _hidden_ performance issue.
>>
>> And how does it introduce a hidden performance issue. You'd end up with some template bloat, but that's it, and that's just going to increase the memory footprint of your program slightly, which isn't generally going to be a performance issue. It's just going to make your program slightly larger.
>>
>> - Jonathan M Davis
>
> instruction cache misses can really hurt

Well, if you're caring about stuff on that level, then you really need to understand what kind of code the compiler is generating, and most anything you do to the program risks changing its performance. So, I don't see much reason to worry about how a slight increase in program size from templatizing a function using auto ref could introduce cache misses. The fact alone that you've templatized the function could change its code gen enough to do that given that the compiler is then guaranteed to have the code available and will be doing attribute inference and whatnot. And most code probably won't see a performance difference anyway. Performance-intensive stuff may care, but you need to be very careful when tweaking that sort of code anyway, simply because all kinds of small tweaks can have unexpected impacts on performance.

- Jonathan M Davis

On Tuesday, 23 June 2015 at 17:05:41 UTC, John Colvin wrote:
> On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis wrote:
>> On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
>>> [...]
>>
>> And how does it introduce a hidden performance issue. You'd end up with some template bloat, but that's it, and that's just going to increase the memory footprint of your program slightly, which isn't generally going to be a performance issue. It's just going to make your program slightly larger.
>>
>> - Jonathan M Davis
>
> instruction cache misses can really hurt

any time spent optimizing for this would be better spent making GDC/LDC 'good enough' to replace dmd.

On 06/23/2015 03:01 AM, Andrei Alexandrescu wrote:
> On 6/22/15 4:09 PM, Timon Gehr wrote:
>> There is no reason to prevent templates from using the mechanism that
>> generates only one copy. The two mechanisms shouldn't share the same
>> syntax, because then there is no way to tell them apart for template
>> functions.
>
> I understand. For my money I'd be okay with what's being proposed
> instead of complicating the language yet again for

We're introducing a new feature either way. I don't agree that the proposed hack complicates the language any less.

> the perfect solution.

We might as well do it right. Why promote unnecessary template bloat?