> On 4 Oct 2017, at 13:55, Mike Kluev <[email protected]> wrote: > > On 4 October 2017 at 13:41, Alex Blewitt <[email protected] > <mailto:[email protected]>> wrote: >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> speaking of &&, was it just a copy-paste from C or is there a more >> fundamental reason to use that instead of &? in C they had to use two >> different operators because of the implicit int <-> bool promotions, but in >> swift "true & false" vs "1 & 2" would have been distinguishable. > > The difference between the & and && operators isn't to do with the implicit > conversions; it's to do with whether both sides of the expression are > evaluated or not. > > false && system('rm -rf') > > You really don't want to do that if both sides are executed ... > > true. however what would stop the hypothetical "logical &" operator to not > evaluate the right hand side if the left > side is false similar to how && behaves? yes, it would make it more different > to the "bitwise &" operator, but they are > already a bit different.
Whether you are dealing with boolean/int types and whether you short-circuit the operators are orthogonal concerns. > (it was always backwards to me even in C: bitwise *single* & is for and-ing > *multiple* bit pairs, whilst a > *multi-character* && is for and-ing a single bool pair.) The && (c.f. ||) is explicitly for short-circuiting and is nothing to do with bit pairs or booleans, by specification. See e.g. section 6.5.13 and 6.5.14. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf Alex
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
