To be honest, I generally think that having two sub-expressions
with visible side-effects in the same expression is not great practice,
even if Go does guarantee order of evaluation.
...in my case, I had an expression rewrite system (think DeMorgan’s
theorems) with boolean functions for the values and I was in fact counting
on each function being visited. I realized that && and || were my nemesis,
so I switched to integers, considering the lack of & and | for bool types a
loss for completeness and stayed away from bool since.
I don't know what I was thinking about the address-of-bool issue. I
remember it plainly but testing it just now I see that it works fine.
Hmm... Makes me feel old.
On Mon, May 8, 2017 at 12:45 AM, roger peppe <rogpe...@gmail.com> wrote:
> On 7 May 2017 at 02:00, Ian Lance Taylor <i...@golang.org> wrote:
> > On Fri, May 5, 2017 at 10:26 AM, roger peppe <rogpe...@gmail.com> wrote:
> >> On 5 May 2017 at 14:11, Michael Jones <michael.jo...@gmail.com> wrote:
> >>> Just so. One cannot do boolean arithmetic with boolean variables.
> >>>
> >>> We have:
> >>> EQUIVALENCE ("==")
> >>> XOR ("!=")
> >>> NOT ("!") -- George Boole's NEGATION
> >>>
> >>> We lack:
> >>> AND ("&") -- George Boole's CONJUNCTION
> >>> OR ("|") -- George Boole's DISJUNCTION
> >>>
> >>> As it happens, one can implement all the operators from the basis of
> >>> NEGATION and either CONJUNCTION or DISJUNCTION, but as we lack each of
> the
> >>> last two, one must be sure to use ints where bools would be natural.
> >>
> >> I don't get it. What's the difference between a&&b
> >> and the hypothetical a&b for two expressions a and b,
> >> assuming a and b are free of side-effects ?
> >
> > There is none.
> >
> > But sometimes b has a side-effect. And sometimes you want that
> > side-effect to be executed whether or not a is true. Then writing `a
> > && b` does not work, and the alternatives are either verbose or
> > require introducing a new temporary variable name.
>
> If you're doing it a lot, then you could always do:
>
> func and(x, y bool) bool { return x && y }
>
> To be honest, I generally think that having two sub-expressions
> with visible side-effects in the same expression is not great practice,
> even if Go does guarantee order of evaluation.
>
--
Michael T. Jones
michael.jo...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
