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
