

Swift Thinking [video] - arrspdx
http://realm.io/news/swift-thinking

======
tolmasky
Most these operator discussions seem to go down the same way: "man you can
make some really confusing operators, and I hope that doesn't become a
thing... but gee writing == is so much nicer than isequalto and can't beat the
+ operator when adding things together!". People seem convinced that its all
or nothing. Lua has such a nice compromise to this: you _can_ overload +, -,
==, etc using special methods (__add, etc.), and you can't overload or create
any new operators. Its a completely controlled environment that disarms the
"but what if I want to add complex numbers together!" argument while still
removing the temptation to create really absurd syntax (which Swift has taken
to the next level with emoji).

~~~
chrisdevereux
I for one can't wait to create circular references between objects that then
stay alive together for ever and ever using the ❤❤❤ operator.

More seriously, I wonder why user-defined operators are considered any worse
than user-defined functions. I mean, I think that they often are, but I wonder
why.

Maybe we assume less potential for ambiguity when we read a symbol than when
we read a word. The possibility that isEqual: has a bad implementation that
doesn't respect transitivity seems more obvious than the possibility that ==
does.

~~~
sparkie
User-defined operators are bad when they betray our expectations of what they
should be doing - and by that, I mean if they don't exist in textbooks which
are decades/hundreds of years old (and thus, almost universally accepted as
part of our languages/cultures), they're gimmicks. That includes =~ for
matching regular patterns - nobody would _ever_ expect this to be the case -
only someone who has encountered it in an existing language will use it as
such.

User defined functions have _names_ that we can understand, because we already
share a common language - English. If we started "making up our own words" for
functions, then we're doing just as bad as user-defined operators - nobody
will recognize what the hell we're doing without looking up their
implementations. It's like reading obfusticated code, or code in some language
you don't know. If every programmer invents his own operators, good luck ever
getting shit done - people don't have the time to learn some arbitrary
language you conjure up just for the sake of shaving a few characters off
code. Nor should anyone need a PhD in mathematics to understand the strange
notations in your examples/proofs.

Operators cannot be searched for in the same way ASCII text can - we need
specialized search engines which don't ignore characters - and they generally
need to be written on a per-language basis to be useful. I think the time
wasted doing this far exceeds the benefits user-defined operators provide.

Also, many unicode characters look alike, and it may be possible to utilize
this in malicious ways where arbitrary characters may be used - by assuming
someone reading/reviewing code will not look up the code points of every
character. Having a limited set of characters makes it pretty simple to
distinguish each one, unless you have poor fonts and can't make out
differences between 1,I,l etc.

Operators are useful for sure, but they're never _necessary_. More to the
point, they are _just_ functions - treating them specially is silly, because
it's much more useful to abstract over functions of any arity than to abstract
over only binary functions.

------
lxcid
If you watch the video and wondering about the multiple subscripts prepended
by '?', this technique is called optional chaining. It also work for
properties and methods.

It is kinda similar to how we can invoke methods on 'nil' in Objective-C and
not causing any runtime error.

Just stating if anyone is wondering.

------
austinz
Interesting that the Apple-provided sample app mentioned around 7 minutes in
uses "~=" as a custom operator, given that it's already defined for use with
pattern matching (match an input with some sort of pattern), and intended to
be overloaded for that purpose. I wonder if this is just an oversight?

~~~
delinka
The pattern matching example he showed from a few other languages uses =~
instead of ~=. This, however, illustrates the potential confusion with
operators that appear to be similar at first glance.

