Dave, thank you for going through the effort to share your reasoning!
>
...
>> Please do not resort to such
>> horrid kluges as using those *flow control operators* when you should
>> be using a *boolean operator*!
>
> "and" is the same boolean operator as "&&" with the same semantics with
> regard to short circuiting (which makes both useful for flow control).
The
> only difference is precedence which is much lower in case of "and". Why
are
> you making this distinction between "boolean operators" and "flow control
> operators"?
Precedence makes a huge difference. The lower precedence of "and" and
"or" makes them horribly misleading in a normal boolean expression
where you're trying to calculate the resulting truth value. This is a
violation of one of Ruby's core principles, that of Least
Astonishment.
People tend to forget that the principle of least surprise applies to Matz.
This is an important restriction that changes semantics quite a bit. See
http://www.artima.com/intv/ruby4.html
They are much more commonly used (at least in correct
code) for flow control, in Perlish idioms such as "do_this and
do_that" (do this, and only if that succeeded, assuming that it
returns a boolean value to indicate success or failure, proceed to do
that) and "do_something or give_error_message" (do something, and if
that fails, making the same assumption, then give an error message).
Ruby has perfectly good idioms for these situations, that is even
clearer (no surprise when comparing against Perl): "do_that if
do_this" and "give_error_message unless do_something".
Actually I use both idioms. I would use "if" only if "do_this" is a test of
some kind. I would use "and" if "do_this" was some kind of task that can
end successfully or not and I want to "do_that" only if "do_this" was
successful.
>> Better yet, just forget the verbal versions even exist. Unless you're
>> coming from Perl, they are unnatural and misleading.
>
> Every language has its idioms. That "and" and "or" are "banned" (see
[1]) is
> completely new to me. And I don't see an issue with using them. They are
> handy for exactly these kinds of situations and where you want to make
code
> human readable. Of course you need to be aware of their properties - but
> that is true for all the other language constructs as well.
But their properties are not at all obvious!
Define "obvious". 
Seriously, all language constructs have properties
that cannot be seen immediately. We have to learn them. Maybe you mean with
"obvious" here something like "function the same was as in other languages
X, Y and Z". But these languages often do not have something like operator
"and" and people will have to learn this new thing anyway.
They masquerade as the
normal boolean operators, simply more humanized versions of && and ||,
while they certainly are not at all equivalent, leading to astonishing
bugs. It's usually not until one has been sorely bitten by such a
bug, or see it discussed, that one finds out about this vital
difference.
I can only speak for me: I learned about the different precedence right
from the start so to me they never "masqueraded" as anything else.
>> See http://bit.ly/RubyGotchas (the slides from my
>> Ruby Gotchas presentation) for details, the slides
>> titled "and != &&" and "or != ||".
>
> What style guide are you referring to? I would like to hear some more
> reasoning. The style guide I found [1] just states not to do it but does
not
> give a reason as far as I can see.
...
> [1] https://github.com/bbatsov/ruby-style-guide#no-and-or-or
Frankly I now forget which one I had in mind, but it was most likely
either that one or Github's, which borrows heavily from it. You're
right that it is light on the reasoning. I believe it's because the
use of "and" and "or" looks tempting to people (not necessarily even
just newbies!) trying to make the code more human-readable, but
introducing subtle bugs that arise from the difference in precedence.
Both guides say "It's just not worth it"; I believe that what they
mean is that the slight better readability is not worth the pain of
creating, encountering, and debugging such bugs... especially when
these operators just won't do what you probably want (if you're
looking for a calculation of a boolean value resulting from combining
several things).
I cannot really say how much confusion they create in the community, for me
that problem does not exist. From my memory (which is feeble) I have seen
far more threads here about the confusing properties of class variables
than of "and".
I'll put in a pull request for BBatsov's, providing an example for
better clarity of the bug-potential, plus offering the above
Ruby-idiomatic snippets as alternatives.
It's always good to make reasoning of such rules transparent. You are doing
the community a good service! Thank you!
Kind regards
robert
···
On Sun, Oct 11, 2015 at 8:45 PM, Dave Aronson < ruby-talk.list.2.TRex@codosaur.us> wrote:
On Sun, Oct 11, 2015 at 2:07 PM, Robert Klemme > <shortcutter@googlemail.com> wrote:
> On Sat, Oct 10, 2015 at 1:48 AM, Dave Aronson > > <ruby-talk.list.2.TRex@codosaur.us> wrote:
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can -
without end}
http://blog.rubybestpractices.com/