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

[Swift]

> On Oct 4, 2017, at 6:41 AM, Alex Blewitt via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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>
>>   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.)

Heh, right. That was unintentional. I have system text replacements set up to turn ->, =>, <->, etc in to their Unicode arrow versions: →, ⇒, ↔︎ 

And using words (and even phrases  like “is not”) as operators is totally possible. It would just require the parser to have a known list of all operators, and then greedily match characters as long as there’s an operator that’s prefixed by the current token, and then backtrack when it fails. 

I implemented this style of operator definition and parsing in my open source math parsing library: https://github.com/davedelong/DDMathParser 

Dave

>> 
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/fc68f7f2/attachment.html>