Const ref and rvalues again...

[luka8088]

On 13.11.2012 11:00, Era Scarecrow wrote:
> 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)).

Can you point out any existing public code that would be broken ?