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
···
On Jan 7, 2016, at 5:26 PM, Jo Albright <me@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@apple.com <mailto:clattner@apple.com>> wrote:
On Jan 7, 2016, at 1:31 AM, Jo Albright via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.mdI 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.