Can we just have struct inheritence already?

Manu turkeyman at gmail.com
Fri Jun 14 06:05:02 UTC 2019


On Thu, Jun 13, 2019 at 9:02 PM Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Thursday, June 13, 2019 9:22:48 PM MDT Walter Bright via Digitalmars-d
> wrote:
> > On 6/13/2019 6:05 PM, Timon Gehr wrote:
> > > If the result is mutable, there should be no common subexpression
> > > elimination because it affects aliasing, but for immutable results, the
> > > compiler should be allowed to pool identical values at its own leisure.
> > > (Note that this is not currently done.)
> >
> > I've suspected for a long time that the value of pure functions is not
> > CSE, but the knowledge that there aren't side effects. Side effects are
> > the bane of understanding code.
>
> Given how restricted the situations are when you can elide function calls
> with pure functions (especially without doing code flow analysis), I don't
> see how it's really any benefit at all aside from maybe math code. IIRC,
> duplicate pure function calls currently only get elided within the same
> expression, but even if it were within the same statement, that sort of
> thing is pretty rare outside of code that's doing math.
>
> On the other hand, knowing that a pure function doesn't access anything that
> it's not given is of value even if you have no strongly pure functions in
> your code anywhere.
>
> So, I've defintely come to the conclusion that functional purity really
> isn't one of the benefits (let alone the primary benefit) of D's pure in
> practice.

FWIW, I have a codebase where `pure` has immense value, because it's
so highly multi-threaded, that any impure operation can not be trusted
not to crash spectacularly.
We need confidence that work functions absolutely do not back-door
access any data. So it's a confidence and correct-ness thing for us,
not an optimisation thing.


More information about the Digitalmars-d mailing list