I think the danger of abuse is stronger when you overload existing operators than when you make up new ones. The latter can't fool you on its semantic and behavior.

I bet we will see some interesting examples of fooling in obfuscated Swift contests.

For example one can define operators called <>, =<, =>, and !=

You can do interesting stuff with pre- and suffix operators, too. For example, the XML comments <!-- and --> could be a prefix- and suffix operator pair.

Also, you could define operators that look conspicuously like comments, at least to some of your readers.

[disclaimer: I don't have access to the code; I just read the documentation. That documentation seems to imply that // starts a comment _and_ can be used to implement a custom operator. Even if that isn't possible (fairly likely, I would say, you can still try using --- or /// as your operator]

Ok, let me replace my “can’t” with “is a lot less likely to”.

I checked: neither // nor /// can be used as operators (syntax error: they both just start a comment). All your other examples work, but I would say those mean the author is intentionally trying to trick me. Or he’s writing a clever DSL, but that line is very fine and treacherous.

Thanks for the checking. And I agree: that line is thin.

Some other food for thought:

  a = b-- // !z
  x = y--// ! z

The first does

  a = b - 1

and has a comment, the second calls suffix --// on y, then infix ! On the result and z.

A variation:

  x+ - 3
  x + -3

I think it is fair to say that Swift introduces a new variant of whitespace sensitivity.

Also, the docs do not seem to discuss line breaks inside statements. If they are legal, you can do:

  x+
  -3

vs

  x+{space}
  - 3

I think I would find it fun to stress test this language.

I don't know whether this is reassuring or worrying, but Haskell has long (always?) pursued this strategy of allowing even more flexible operator names. From http://www.haskell.org/onlinereport/lexemes.html:

> Operator symbols are formed from one or more symbol characters, as defined above …

where 'above' is:

    symbol 	-> 	ascSymbol | uniSymbol<special | _ | : | " | '>
    ascSymbol 	-> 	! | # | $ | % | & | * | + | . | / | < | = | > | ? | @
	| 	\ | ^ | | | - | ~
    uniSymbol 	-> 	any Unicode symbol or punctuation

They go so far that the operator name can even be prefixed by the lexeme (?) for single-line comments (--) :)

> (--|) = (+)

My problem with most overloaded operators is that they too often have no sensible name.

When I talk to myself while coding, I have no name to say out loud.

I have nothing but a picture, when I try to remember the operator.

While the names may or may not work for you, this has been considered:

http://stackoverflow.com/questions/7746894/are-there-pronoun...

http://stackoverflow.com/questions/3242361/haskell-how-is-pr...

I got to this by Googling for the 'fish' operator, to which I vaguely remembered seeing a reference:

http://www.reddit.com/r/haskell/comments/c262b/the_fish_oper...

I'm quite fond of being able to define new operators. Particularly in functional languages, it allows you to effectively extend the language. For example, F#'s designers didn't include the usual monad operators. It's easy enough to define your own >>=, though, so life is still good. Similarly, ML developers can create their own forward application ( |> ) operator to also get good access to a useful feature that isn't included by default.

In languages that don't allow you to overload operators at all, the alternative is to use explicit function syntax. That can sometimes be a short path unreadable to code that's littered with pyramids of doom.

In languages that only allow you to overload existing operators, you end up with monstrosities like C++'s << and >> operators, which overload the bit-shift operators with new and completely unrelated semantics. It's that kind of shenanigans that give operator overloading such a bad name.

> Operator overloading can potentially be abused because in Swift you are not limited to standard operators like in C++.

It is both a blessing and a curse, as far as potential for abuse is concerned.

You pointed out the downside of arbitrary operator names. The downside of operator overloading on fixed operator names is that you are limited in your choice of operators, so instead of choosing a more distinct operator, you sometimes have to go with things that are kind-of-the-same, or maybe not close at all. And instead you also have the problem of misleading people, for example by using the +-operator for set union, while the reader thinks you are adding together numbers.