Taking arguments by value or by reference

[IGotD-]

On Saturday, 3 October 2020 at 23:00:46 UTC, Anonymouse wrote:
> I'm passing structs around (collections of strings) whose 
> .sizeof returns 432.
>
> The readme for 2.094.0 includes the following:
>
>> This release reworks the meaning of in to properly support all 
>> those use cases. in parameters will now be passed by reference 
>> when optimal, [...]
>>
>> * Otherwise, if the type's size requires it, it will be passed 
>> by reference.
>> Currently, types which are over twice the machine word size 
>> will be passed by
>> reference, however this is controlled by the backend and can 
>> be changed based
>> on the platform's ABI.
>
> However, I asked in #d a while ago and was told to always pass 
> by value until it breaks, and only then resort to ref.
>
>> [18:32:16] <zorael> at what point should I start passing my 
>> structs by ref rather than by value? some are nested in 
>> others, so sizeofs range between 120 and 620UL
>> [18:33:43] <Herringway> when you start getting stack overflows
>> [18:39:09] <zorael> so if I don't need ref for the references, 
>> there's no inherent merit to it unless I get in trouble 
>> without it?
>> [18:39:20] <Herringway> pretty much
>> [18:40:16] <Herringway> in many cases the copying is merely 
>> theoretical and doesn't actually happen when optimized
>
> I've so far just been using const parameters. What should I be 
> using?

I don't agree with this, especially if the struct is 432 bytes. 
It takes time and memory to copy such structure. I always use 
"const ref" when I pass structures because that's only a pointer. 
Classes are references by themselves so its not applicable there. 
Only "ref" when I want to modify the contents.

However there are some exceptions to this rule in D as D support 
slice parameters. In this case you want a copy as slice of the 
array, often because the slice is often casted from something 
else. Basically the array slice parameter become an lvalue.

This copy of parameters to the stack is an abomination in 
computer science and only useful in some cases but mostly not. 
The best would be if the compiler itself could determine what is 
the most efficient. Nim does this and it was not long ago 
suggested that the "in" keyword should have a new life as such 
optimization, is that the change that has entered in 2.094.0? Why 
wasn't this a DIP?

I even see this in some C++ program code where strings are passed 
as value which means that the string is copied including a 
possible memory allocation which certainly slow things down.

Do not listen to people who says "pass everything by value" 
because that is in general not ideal in imperative languages.