Fully transitive const is not necessary

[Steven Schveighoffer]

"Georg Wrede" wrote
> Walter Bright wrote:
>> Bill Baxter wrote:
>>
>>> So does that mean
>>>
>>>   pure int f(const Class c)
>>>   { ...
>>>   }
>>>
>>> will *not* be allowed?  Because some part of c *could* change, even if 
>>> it's not f() doing the changing.  I.e. another thread could be changing 
>>> c concurrently.
>>
>> Right. That declaration of f is erroneous.
>
> I'd disagree.
>
> Whether a function is pure or not, has nothing to do with whether c could 
> change or not.

The question is, should pure functions be protected from other threads 
changing c?   I think Walter wants this to be true, and for that, c must be 
invariant.  I think Walter is trying to promote a different definition for 
pure than what you are thinking of.

>
> Take, for example sin(x). We all know that it's pure, period. Now, whether 
> x changes between two consecutive invocations or not, is irrelevant. Of 
> course you get a different result. And you should.

sin(x) is a completely different animal, because x is not a reference type, 
it is pushed on the stack, and the pure function has the only reference to 
it.  Nothing can change x while sin is running.

>
> But pure, IMHO, means (1) the function is guaranteed to give the same 
> result every time /if/ the input is the same (like sin(x) does), (2) it 
> does not change anything at all anywhere, it's only way of affecting life 
> is by its return value, (3) it doesn't access info from non-constants 
> anywhere.
>
> Now, to the issue between
>
>     (1)pure int f(const Class c)
>     (2)pure int f(Class c)
>
> I'd say that, since a Pure function promises not to change /anything/ 
> (other than its return value, of course) anywhere, this means a pure 
> function /simply has to implicitly treat its arguments as unchangeable/!
>
> Therefore, depending on what A/W want, either:
>
>  - a pure function has to have const decorated parameters only (1)
>  - and (2) would be a syntax error
>
> or
>
>  - a pure function's parameters are implicitly const, and (1) is then a 
> syntax error

If the arguments must be invariant, then they cannot be implicitly cast.  I 
understand what you are saying, but I think A/W want something different.

>
> (Not making the latter a syntax error isn't technically impossible, but 
> for those learning the language and the casual readers of ex. magazine 
> articles, this would wreak havoc with their understanding D.)
>
>
> *Back to concurrency*, if someone changes c in mid-run, then it's the 
> programmer's fault. It's his headache. The function f only guarantees not 
> to change c /by itself/.

I think this is what A/W want to prevent.  Otherwise, all this touting about 
pure functions being the way to multiprogram in D is not completely true, 
you still have to deal with multithreadded issues.  Walter has said before 
he wants multithreaded programming to "just work" without having to do any 
locking, just like FP languages have.

-Steve