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

[Alex Blewitt]

> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong <swift at davedelong.com <mailto:swift at davedelong.com>>
>   wrote:
> 
> > Because, ideally, I’d love to be able to do:
> > 
> > infix operator and: LogicalConjunctionPrecedence // or whatever the precedence is called
> > func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs }
> > 
> > let truthyValue = true and false
> 
> +1 (i like your thinking, even if it is unlikely to happen in swift)
> 
> (noteworthy, your example used "RIGHTWARDS ARROW" (U+2192) instead of ->, whether on purpose or not.)
> 
> 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 ...

Alex

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