[Issue 7456] Purity strength not documented
https://issues.dlang.org/show_bug.cgi?id=7456 berni44 changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@d-ecke.de Resolution|--- |WORKSFORME --- Comment #5 from berni44 --- Seems to be documented meanwhile: https://dlang.org/spec/function.html#pure-functions --
[Issue 7456] Purity strength not documented
https://d.puremagic.com/issues/show_bug.cgi?id=7456 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #4 from yebblies 2014-01-15 19:55:43 EST --- (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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7456] Purity strength not documented
https://d.puremagic.com/issues/show_bug.cgi?id=7456
--- Comment #3 from Don 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: ---
[Issue 7456] Purity strength not documented
https://d.puremagic.com/issues/show_bug.cgi?id=7456 Peter Alexander changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #2 from Peter Alexander 2014-01-11 16:16:52 PST --- (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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7456] Purity strength not documented
http://d.puremagic.com/issues/show_bug.cgi?id=7456 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2012-02-07 10:30:43 PST --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
