On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil <jaydu...@gmail.com> wrote:
> > Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist < > blomqvist.ja...@gmail.com>: > > >Either > > > >a) short-circuiting in left-to-right order > > > >or > > > >b) must evaluate all the arguments in left-to-right order > > > >My preference would be for a) as that is what most languages are doing, > > Well, C/C++ has two different kinds of operators that give you the choice > to specify whether you want short-circuiting or not. > Presumably you're thinking of "&" and "|". But to be pedantic, those are bitwise operators, not non-short-circuiting boolean operators, although in some cases they can be used as such. There are however situations where they are not equivalent to hypothetical non-short-circuiting boolean operators! >but > >even b) would be better than leaving it undefined. > > Agreed. > > In my opinion the best strategy for gfortran in the current situation > would be to apply short-circuiting whenever it can be proven that it has no > observable consequences. E.g. a function call should not be optimized away > unless it is pure. > Hmm, why? I don't see why always evaluating everything is less wrong than short-circuiting? I think the best we can do is to print a warning, and try to pressure the committee to choose an evaluation strategy so that this unfortunate situation could eventually be resolved (is Toon still on the committée?). > >Also, there are AFAIU other similar weirdness with impure functions. > >The > >standard allows a compiler to optimize > > > >y = f(x) + f(x) > > > >into > > > >y = 2 * f(x) > > > >even if f is impure, which is totally bonkers. Or even not call f at > >all, > >if the compiler determines that y is not needed. > > Yes, that is the same kind of craziness. I hope gfortran does not actually > do this? > I would hope so too, but I haven't verified. -- Janne Blomqvist
