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

[Mike Kluev]

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

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/87ff4997/attachment.html>