[Issue 7456] Purity strength not documented

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jan 14 06:57:05 PST 2014


https://d.puremagic.com/issues/show_bug.cgi?id=7456



--- Comment #3 from Don <clugdbug at yahoo.com.au> 2014-01-14 06:56:48 PST ---
(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.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list