*in* vs *const ref*

[Dan]

Very clear and much appreciated.

On Tuesday, 6 November 2012 at 23:38:00 UTC, Jonathan M Davis 
wrote:
> If a function requires an lvalue, then you have to pass a
[snip]
> You'd have to do something like
>
> string file = __FILE__;
> size_t line = __LINE__;
> auto f = foo();
> auto b = bar(7);
>
> writefln("%s(%s): stray message %s: %s", f, b);
>
> That would be _really_ annoying. And the same goes for 
> functions in general.
> Functions which require lvalues are generally not user friendly 
> unless you're
> specifically looking to alter the variable passed in, in which 
> case const ref
> doesn't do what you want anyway.

Yeah - that would be quite annoying. I would say it like 
"functions which require lvalues are generally not *programmer* 
friendly, but as the size of the struct grows they do become 
*user* friendly."

>
>> Also, it does not mention *in ref*, which I guess is same as
>> *const ref* but with *scope*.
>
> Yes. in is an alias for const scope, ad I would advise avoiding 
> scope as much
> as possible (so, I'd advise avoiding in as much as possible).

Ok. Taking this into account I'll avoid *in*. My new heuristic 
for setters (and struct param passing in general) will be to 
choose between *const ref* and no storage specifier at all. For 
small structs (say < 32 bytes) I'll just have (T t) and for large 
structs I'll have (const ref T t). I don't see why the compiler 
can't determine that for me and keep it transparent. I guess if 
it did make such an arbitrary decision many people would be upset.

Thanks
Dan