[swift-evolution] A path forward on rationalizing unicode identifiers and operators
alblue at apple.com
Wed Oct 4 08:12:22 CDT 2017
> On 4 Oct 2017, at 13:55, Mike Kluev <mike.kluev at gmail.com> wrote:
> On 4 October 2017 at 13:41, Alex Blewitt <alblue at apple.com <mailto:alblue at apple.com>> wrote:
>> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution