On Wednesday, 7 November 2012 at 03:13:22 UTC, martin wrote:
void func1(ref int x); //D lvalue-only ref
void func2(@ref int x); //works like c++'s ref
Seems fairly easy to tell apart, and still leaves const-ness
as an option.
Afaik C++ doesn't allow rvalues to be passed to _mutable_
references (T&), only to const references, making perfect sense
imo. I really do not see the point for an additional syntax for
C++-like const references (const T&) which would also take
rvalues.
Please give me an example where you want to pass an rvalue to a
_mutable_ reference parameter. I would simply continue to
disallow that, since that would mean that changes to the
referenced rvalue would not be visible for the caller (a
temporary/literal is changed - how could someone possibly want
that?).
Still that zlib entry is coming to mind. But more importantly is
that you still need code duplication to get both accessible.
//many possible combinations thereof
int func(const ref x);
int func(int x) {
return func(cast(const int) x);
}
But regarding zlib.. It's function is something like:
int compress(char *output, int *size, char *input, int
inputSize);
So... if we convert that to something similar we get..
enum ZlibEnum {}
ZlibEnum compress(void[] output, void[] input, &ref Zlib state)
nothrow pure;
The idea in this case is 'state' would continue to hold the
input/output pointers and all information needed, so you could
continue to use it and if it has any 'unflushed' data (output
size too small?) then it could retain that. however if you knew
you didn't need it you could ignore it.
ZlibEnum could be for output C calling code, so success/failure
needs to be known right away. It makes sense for it to return a
Zlib type as well, but depends on what has higher priority and
why.
string input = "something long";
ubyte[1000] output;
ubyte[5] output2;
Zlib state;
compress(output, input, null); //we know the buffer is large
enough
compress(output2, input, state);
