[swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Alex Blewitt]

> 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.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/27f2d22e/attachment.html>