On Thu, 23 Sep 2010 02:57:28 -0400, Don <nos...@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.
