

Interesting Swift Features - ingve
https://www.mikeash.com/pyblog/friday-qa-2014-06-20-interesting-swift-features.html

======
vijayaggarwal
Explicit optionals are great. But I feel some of the other convenience
features like type inference, trailing closures, different copy behavior of
arrays, and _operator overloading_ have the potential of being abused to
produce cryptic code. What's your opinion?

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

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html)

According to the documentation you can declare an operator composed by an
arbitrary list of this characters "/ = - + * % < > ! & | ^ . ~". You can
recreate C++ stream operators (<<, >>), Ruby combined comparison (<=>), and so
on.

~~~
JadeNB
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](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

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

> (--|) = (+)

~~~
Flow
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.

~~~
JadeNB
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/7746894/are-there-
pronounceable-names-for-common-haskell-operators)

[http://stackoverflow.com/questions/3242361/haskell-how-is-
pr...](http://stackoverflow.com/questions/3242361/haskell-how-is-pronounced)

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...](http://www.reddit.com/r/haskell/comments/c262b/the_fish_operator)

------
apayan
Google cache because the site is down:
[http://webcache.googleusercontent.com/search?q=cache:Z3RhU-_...](http://webcache.googleusercontent.com/search?q=cache:Z3RhU-
_bgzkJ:https://www.mikeash.com/pyblog/friday-qa-2014-06-20-interesting-swift-
features.html&client=firefox-a&hl=en&gl=us&strip=1)

~~~
mikeash
Thanks for posting that. I don't know if it was the HN Hug of Death or a
coincidence or what, but the VPS spiked to 100% CPU and became completely
unresponsive, even in the console accessed through the host's web panel. A
reboot has fixed it... for now.

------
prof_hobart
Don't know whether it's just because a lot of the library code hasn't been
fully moved to this model yet, but I'm still finding most (possibly all) of
the iOS API code to use the same error:&error) approach that Objective C uses.

~~~
eridius
Approximately none of the iOS APIs have been adjusted for Swift yet.

Also, at least for Swift 1.0, they won't be. Swift does not guarantee a stable
ABI right now or for 1.0. They guarantee binary compatibility with the OS, and
ABI compatibility with any application frameworks that are compiled alongside
the application (because, well, those can't change), but no compatibility
between frameworks and applications. The only way to get that compatibility is
to stick to Obj-C APIs (or, well, pure C APIs, but that's no better).

What this means is system frameworks will not be able to take advantage of
things like generics or multiple return types until sometime in the future,
past Swift 1.0. Of course, they couldn't justify doing that today anyway,
because they need to maintain Obj-C compatibility for all of the Obj-C code
that still exists.

------
micampe
It's a small thing but I think let/var deserved a mention too (my C code is
littered with const everywhere).

~~~
rsfinn
He did say he was going to write a series of articles about Swift. Give him
time. :-)

The main "aha" point of this article for me was the way optional values
eliminate a whole class of programming errors that are pervasive in the "C
family" of languages, and does so in a rather elegant way. (Apparently Scala
has a similar capability, but I'm not familiar with Scala.)

~~~
derefr
People are probably most familiar with them, I think, in the form of Haskell's
Maybe monad. (Though that has the extra feature of black-holing computations
that try to operate on Nothing.)

~~~
bronxbomber92
Swift has the "black-holing" as well in the form of either explicitly calling
Optional's map method, or the syntactic sugar: myTypeTOpt?.methodOnTypeT()

