Proposal: Relax rules for 'pure'

[Robert Jacques]

On Thu, 23 Sep 2010 02:57:28 -0400, Don <nospam at nospam.com> wrote:

> Robert Jacques wrote:
>
>>>>>>> The point of the proposal is *not* to provide the weak guarantee.  
>>>>>>> It is to provide the strong guarantee in more situations.
>>>>>>  The problem from my point of view is that the programmer can not  
>>>>>> declare that a function should be 'strongly-pure' or 'weakly-pure'.
>>>>>
>>>>> Yes they can. They just need to declare the parameters to be  
>>>>> immutable.
>>>>
>>>> What about value types?
>>>
>>> Value types are implicitly convertable to immutable, so they can be  
>>> strongly-pure.
>>  No their not. Remember, arrays and other structs are value types in  
>> the type system. Logically, they may be reference types, but as far as  
>> their type signature goes, they are value types.
>>
>>> The problem I think Robert is referring to is, a person cannot always  
>>> tell just from looking at a signature that a type is strongly-pure  
>>> qualified or not.
>>  And that you can not manually specify one or the other.
>
> Yes you can. Just add const to the parameter declaration. This works  
> because const is transitive.
>
>>
>>> For example, is this function weak or strong?
>>>
>>> pure int foo(T t);
>
> pure int foo(const T t);
>
> is always strong pure, regardless of what T is.

Don, this isn't always strong pure, regardless of what T is. Consider:

auto x = foo(t);
t.mutate;
auto y = foo(t);

The value of foo(t) can not be either cached nor parallelized.

I think what you meant was to just add immutable to the parameter  
declaration. i.e. pure int foo(immutable T t); And to answer my own  
question from earlier in the thread, this works because the automatic  
conversion of value types is done in a transitive manner. So if someone  
adds an indirection inside T, foo(t) will then fail to compile, because  
the implicit conversion of T to immutable(T) will fail. Having to specify  
all value-types as immutable is a bit annoying inside the function, as  
shadow variables would have to be used to make inputs mutable again, but  
this does satisfy the need to force a function signature to be  
strongly-pure.