There is some debate as to whether they even should be. pure is defined quite correctly in the spec. weak vs strong purity is arguably just an implementation detail used for optimizations. I believe that this is Don's take on it (he's both the one who came up with strong vs weak purity and the one who updated the spec when pure was changed).
Now, weak vs strong purity inevitably comes up when people get confused by why the compiler allows what are weakly pure functions to be pure (particularly when compared with what TDPL says - though I think that many just look at it from a functional perspective and are confused even without having read TDPL). So, there is arguably merit in defining them somewhere. But I believe that Don's against it. He's mentioned before that he wants the terms to go away entirely.
Comment #2 by peter.alexander.au — 2014-01-11T16:16:52Z
(In reply to comment #1)
> There is some debate as to whether they even should be. pure is defined quite
> correctly in the spec. weak vs strong purity is arguably just an implementation
> detail used for optimizations. I believe that this is Don's take on it (he's
> both the one who came up with strong vs weak purity and the one who updated the
> spec when pure was changed).
>
> Now, weak vs strong purity inevitably comes up when people get confused by why
> the compiler allows what are weakly pure functions to be pure (particularly
> when compared with what TDPL says - though I think that many just look at it
> from a functional perspective and are confused even without having read TDPL).
> So, there is arguably merit in defining them somewhere. But I believe that
> Don's against it. He's mentioned before that he wants the terms to go away
> entirely.
Implicit conversion to immutable is only allowed with strongly pure functions, so purity strength has semantic differences, not just implementation differences. These must be documented.
Comment #3 by clugdbug — 2014-01-14T06:56:48Z
(In reply to comment #2)
> (In reply to comment #1)
> > There is some debate as to whether they even should be. pure is defined quite
> > correctly in the spec. weak vs strong purity is arguably just an implementation
> > detail used for optimizations. I believe that this is Don's take on it (he's
> > both the one who came up with strong vs weak purity and the one who updated the
> > spec when pure was changed).
> >
> > Now, weak vs strong purity inevitably comes up when people get confused by why
> > the compiler allows what are weakly pure functions to be pure (particularly
> > when compared with what TDPL says - though I think that many just look at it
> > from a functional perspective and are confused even without having read TDPL).
> > So, there is arguably merit in defining them somewhere. But I believe that
> > Don's against it. He's mentioned before that he wants the terms to go away
> > entirely.
>
> Implicit conversion to immutable is only allowed with strongly pure functions,
> so purity strength has semantic differences, not just implementation
> differences. These must be documented.
Actually there are a lot more than two strength levels. There are pure functions with mutable parameters, pure functions with const parameters, pure functions with immutable parameters, and pure functions with only value parameters.
Consider
struct S { int b; }
long [] foo( const S * s) pure
The return value will always be unique, and therefore potentially castable to immutable, even though the input parameter isn't immutable.
At the present time, the implicit cast is only permitted when all parameters are immutable or are value types. But at some point in the future we could decide to extend it to any case where it's impossible to have aliasing between parameters and return values.
I don't think there's any need to introduce terminology. Especially not "weak pure" which is highly misleading as there are several levels of weakness.
I just used "weak" and "strong" terms to explain to Walter that 'no globals' is the deep property of purity, whereas 'no side effects' is already handled by the type system.
And "weakly pure" is a bit nonsensical, it's an oxymoron.
But we definitely need to explain what the implicit conversion rule is.
Comment #4 by yebblies — 2014-01-15T00:55:43Z
(In reply to comment #3)
>
> At the present time, the implicit cast is only permitted when all parameters
> are immutable or are value types. But at some point in the future we could
> decide to extend it to any case where it's impossible to have aliasing between
> parameters and return values.
Actually Kenji added some of this a while back, but some of the aliasing checks are wrong/missing.