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(output, input, state);