[swift-evolution] Allowing Characters for use as Custom Operators
Chris Lattner
clattner at apple.com
Thu Jan 7 23:42:20 CST 2016
> On Jan 7, 2016, at 5:26 PM, Jo Albright <me at jo2.co> wrote:
>
> Chris - I really appreciate that you take the time to entertain & respond to proposals.
>
>> On Jan 7, 2016, at 7:24 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>
>>
>>> On Jan 7, 2016, at 1:31 AM, Jo Albright via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> As my obsession grows with custom operators. I have come across wanting to use small words or 1-2 alphabetical characters as custom operators. I noticed that “as” and “is” are character based operators and figured it wouldn’t hurt to propose the allowance of character based custom operators.
>>>
>>> Here are my reasons for allowing them:
>>>
>>> 1. easier to read “within” vs “>*<“ or “|*|”
>>
>> Check out Replace Logical Operators (&&, ||, etc) with words like "and" and “or":
>> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>
> I completely agree with that proposal being rejected. I am not asking to replace existing language grammar. My desire is for the support of alphabetical characters for custom operators to allow third party libraries to have their own unique grammar.
>
>> There is very small win here of “x foo y” over "x.foo(y)”?
>
> And I completely agree that function/method syntax can easily suffice for normal circumstances. Just trying to see how far Swift can be stretched.
Hi Jo,
The rationale is the same - the design of Swift really wants operators and identifiers to be partitioned into different namespaces. Violating that would make it impossible to parse a swift file without parsing all of its imports. This is a mistake that C made (you have to parse all the headers a file uses to reliably parse the file) that we don’t want to replicate in Swift.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/4fc85825/attachment.html>
More information about the swift-evolution
mailing list