Const ref and rvalues again...

[Era Scarecrow]

On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:
> Would it ? How many functions actually change their non ref/out 
> arguments ? Can you point out any existing public code that 
> would be broken ?

  It would be possible that if the language became 
const-preference that a simple regex tool could be made that 
would do the conversions, thereby any code broken in this way 
could be un-broken just as easily; But that assumes you aren't 
using mixins or magic as part of your signatures.

  Somehow this reminds me a little of when I worked at a company 
where we were trying out asp as a web server; The whole VB script 
was by default 'by ref' so you littered all your functions with 
'byVal' in order for your behavior to act as you expected.


  Anyways, my take on this is consistency would be a lot more 
difficult and annoying unless you had different rules for the 
signature vs all other references... I doubt you would say 'this 
is mutable here but immutable here' type of thing. So.... 
assuming 'mutable' is used, then the following would be 
comparable...

//D as of now
int func(int x, int y, const ref int z) {
   int something; //mutable far more likely
   int something2;
   const int lessOften;
}

//then would become...
//if x & y aren't ever changed then mutable may be unneeded.
mutable int func(mutable int x, mutable int y, ref int z) {
   mutable int something;
   mutable int something2;
   int lessOften;      //const (once set)
}

//or for inconsistancy..
//mutable or const as a return? (Or either?)
//and which would/should you use to reverse it?
int func(mutable int x, mutable int y, ref int z) {
   int something;       //mutable
   int something2;
   const int lessOften; //const
}

  Seems in a function body you are far more likely to have mutable 
items, while in the signature you're more likely to have const 
items; But mixing them or changing how you do it would likely 
break code very easily if it isn't signature only, but it doesn't 
seem like a good idea...

  Now in the above the function may not specify 'x' is const it 
doesn't guarantees it ever changes it (but it's a local copy so 
does it matter?), but specifically specifying it may be more 
clutter than actually useful.

  All in all it seems like it would have far more confusion (and 
break code) than help; although having it prefer const versions 
of functions/methods to non-const ones should probably have a 
higher priority (Although you then couldn't have a non-const one 
unless it was as part of the struct/class constness and not the 
variables, (and ref preferred over non-ref)).