Const ref and rvalues again...

[Era Scarecrow]

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);