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