"Ola Fosheim Grøstad" " wrote in message news:cfqevmhbwagvbqvgdlsd@forum.dlang.org...

> No. Make value parameters immutable, period. No mutable version as an option. This does not expose anything to the caller.

The same reasoning applies to making all value parameters mutable. 

On Wednesday, 24 December 2014 at 08:22:46 UTC, Daniel Murphy wrote:
> The same reasoning applies to making all value parameters mutable.

Yes, but my point was that making all value parameters mutable is at odds with correctness when you later edit it since you no longer know whether it has been modified or not.

E.g.

int myfunc(int n){
    ...lotsofstuff...
    x = mayormaynotchange(n);
   ...lotsofstuff...
   return n>0 ? x : 0;  // modified from "return x"
}

On Wednesday, 24 December 2014 at 08:39:26 UTC, Ola Fosheim Grøstad wrote:
> int myfunc(int n){
>     ...lotsofstuff...
>     x = mayormaynotchange(n);
>    ...lotsofstuff...
>    return n>0 ? x : 0;  // modified from "return x"
> }

If you require another variable for a sanitized version of `n`, you get confused, when to use `n` and when to use `x`, they are almost the same and if you pick a wrong value, the code will break sometimes.

On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:
> On Wednesday, 24 December 2014 at 08:39:26 UTC, Ola Fosheim Grøstad wrote:
>> int myfunc(int n){
>>    ...lotsofstuff...
>>    x = mayormaynotchange(n);
>>   ...lotsofstuff...
>>   return n>0 ? x : 0;  // modified from "return x"
>> }
>
> If you require another variable for a sanitized version of `n`, you get confused, when to use `n` and when to use `x`, they are almost the same and if you pick a wrong value, the code will break sometimes.

Not really, because you should strive to keep mutable state local. Validation does not belong to the implementation, so "the right way" is to put it in a wrapper before you call the function that does the actual work.

When functions get long and complicated and evolve over time then all mutable state become a source for errors.

I never want to change parameter values for long functions. I do it for because I am in a hurry. The more constraint the language impose the better code I am likely to write.

On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:
> If you require another variable for a sanitized version of `n`, you get confused, when to use `n` and when to use `x`, they are

Btw, this is case where preventing shadowing becomes an issue, as you could have solved this easily using immutable shadowing:

func(immutable int n){
   @trustmeiwantoshadowthis immutable n = sanitize(n);
   ...
}

On Wednesday, 24 December 2014 at 09:18:43 UTC, Ola Fosheim Grøstad wrote:
> Not really, because you should strive to keep mutable state local.

Even if it's local, there are still many similar values to see:
return n>0 ? x : 0;

> Validation does not belong to the implementation, so "the right way" is to put it in a wrapper before you call the function that does the actual work.

Unlikely to be done. Sanitization is usually done in place.

> When functions get long and complicated and evolve over time then all mutable state become a source for errors.

Just wanted to say immutability doesn't look that fool-proof.

"Ola Fosheim Grøstad" " wrote in message news:ggcloheiypsxdssfvwav@forum.dlang.org...

> Yes, but my point was that making all value parameters mutable is at odds with correctness when you later edit it since you no longer know whether it has been modified or not.
>

Modifying parameters usually falls into one of three classes: (in my code at least)
1. 'fixing' the value (eg removing invalid characters from a string, rounding)
2. reusing the variable
3. consuming the variable (eg popFront on a range)

3 can't be const/immutable, 2 should probably use different variables, but I don't have a problem with 1 being mutable.

> E.g.
>
> int myfunc(int n){
>      ...lotsofstuff...
>      x = mayormaynotchange(n);
>     ...lotsofstuff...
>     return n>0 ? x : 0;  // modified from "return x"
> }

I see this as more of an argument for avoiding long functions.  Marking every possible parameter as const/immutable has a cost, and I don't think the number of bugs it prevents justifies it.  If it was the default the cost wouldn't exist. 

On Wednesday, 24 December 2014 at 02:38:02 UTC, Andrei Alexandrescu wrote:
> On 12/20/14 9:39 AM, Martin Nowak wrote:
>
> Shared semantics and improving multithreading also come to mind. -- Andrei

O God! +1000 ;-P

---
PAOLO

On Wednesday, 24 December 2014 at 10:32:33 UTC, Daniel Murphy wrote:
> I see this as more of an argument for avoiding long functions.  Marking every possible parameter as const/immutable has a cost, and I don't think the number of bugs it prevents justifies it.  If it was the default the cost wouldn't exist.

I want immutable by default, everywhere... Yes.

A lot of the semantics of current programming languages is due to bad habits that was caused by languages designed for less capable backends. When those languages were designed you had to optimize trivial code by hand. C  falls into this category.

On Wednesday, 24 December 2014 at 09:46:11 UTC, Kagamin wrote:
> On Wednesday, 24 December 2014 at 09:18:43 UTC, Ola Fosheim Grøstad wrote:
>> Validation does not belong to the implementation, so "the right way" is to put it in a wrapper before you call the function that does the actual work.
>
> Unlikely to be done. Sanitization is usually done in place.

You could improve this by having "parameterless light weight lambdas":

immutable i = { ...mutable computation...; return x+n; }

Doing things "in place" is kind of pointless if the SSA form in the back-end turns it into immutable anyway. If it is done "proper in place" you no longer have a value type, but a reference type...