On Wednesday, 7 November 2012 at 04:05:32 UTC, martin wrote:
int func(in ref int x);
int func(int x) { return func(x); }
The latter overload is for rvalues (no need to cast to const)
and wouldn't be required if the first one took rvalues directly
(having a _const_ ref parameter). That's not an example for
mutable references though, it's basically a shortcut so as to
not having to declare all rvalues for x manually.
Maybe... But when working with non built-in types can you
guarantee that behavior?
//same as 'const ref' basically, unless 'in ref' is accepted
struct S
//int func(in ref S x); //?
int func(const ref S x);
int func(S x) { return func(x); } //potentially infinitely self
calling
compress(output, input, null);
compress(output2, input, state);
Where's the rvalue? You're talking about an optional mutable
reference here, which is only doable via a pointer (references
cannot be null, not in C++ and not in D):
Perhaps null is wrong in this case, but had it been Zlib.init or
Zlib(), then it would still be applicable. Since it's a reference
I would think it could accept a null pointer and realize to
create a temporary which has it's default values.
That would be correct. But you're completely missing the point
here. Let's assume you wanted to require a state to be passed:
ZlibEnum compress(void[] output, void[] input, ref Zlib state);
You could now use:
Zlib state; // lvalue
compress(output, input, state);
but not:
compress(output, input, Zlib()); // rvalue
And that is most likely a good thing, since your state would be
lost after the compress() call. If you don't want it, you don't
pass it, and as I said, the only way to do that is to pass a
nullable pointer. So this is off-topic I'm afraid.
True, but rather than having to create a temporary you don't
plan on using just to satisfy the signature, and you know you
don't NEED it afterwards, why do you have to go through the extra
steps? How many wrappers are made in general just to work around
minor issues like this?
Quite often we ignore return types if they aren't interesting,
but we can't ignore a rvalue we only need for one call (or just
to satisfy the signature)? Say we have a divide function (who
knows what for), and this is more efficient than normal. So...
//perhaps '@ref int remainder = 0'?
int divide(int number, int divisor, ref int remainder);
Now in this case what if we don't care about the remainder?
Create a temporary (or a wrapper function)?
//satisfy remainder
int divide(int number, int divisor) {
int tmp; return divide(number, divisor, tmp);
}
int modulus(int number, int divisor) {
int tmp; divide(number, divisor, tmp);
return tmp;
}
But if we want the result of the division AND the remainder
should we have to make a separate modulus function when the
original divide can clearly give you the answer? This cuts closer
to the instruction set as an example.
