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

[Mike Kluev]

On 4 October 2017 at 14:24, Alex Blewitt <alblue at apple.com> wrote:

> On 4 October 2017 at 13:41, Alex Blewitt <alblue at apple.com> wrote:
>
>>
>> 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.
>>
>
> However, you can wrap the second argument in an @autoclosure, which means
> it replaces the body of the expression with a function that evaluates the
> expression automatically:
>
> infix operator &&&: LogicalConjunctionPrecedence
>
> func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
> return left && right()
> }
>

great. as you just shown, the difference of short-circuiting or not is not
inside the operator declaration itself (like it is defined in C)
but in the actual operator implementation, so we can have:

infix operator &&&: LogicalConjunctionPrecedence

func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
return left && right()
}

func &&&(left: Int, right: Int) -> Int {
return left & right
}

where the logical one short-circuits and bit-wise one doesn't.

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