The Frequently Rejected Changes document describes the ternary operator ?: as "Definitely magical". I'm not sure I see why you would classify it that way.
In my understanding, "magical" refers to effects that can't be easily reasoned about because crucial information is missing. Hence, magical numbers referring to mappings understood by a blackbox subsystem, magical operators like perl's "while (<>)" doing possibly inscrutable things. The reasoning here is that you have to refer to files or documents not required to be listed in the code to understand what might happen in the code. (And yes, the spaceship operator isn't that magical once you know what it does.)
The ternary is a paragon of clarity when you learn what it does. Everything is right there, the condition in question, and two expressions, exactly one of which will be the supplied value.
Hah. Good point. Love the ternary operator but also understand the fundamental objection. Maybe "magical" is not the right term. A better term might be "cryptic"? Nothing in the Swift ecosystem after all actually runs using magic. (Insert build system joke here.)
Imagine yourself encountering ? : for the first time. How do you pronounce it? How do you search for it so you can figure out what it does? Would someone seeing for the first time realize that that the : is connected to the ? or is it some kind of unwrapped thing with a type annotation. Once you know, it's pretty easy though.
The R language uses ifelse(condition, valueIfTrue, valueIfFalse) which has better properties here.
Amusingly, I don’t have to imagine, I recall seeing it in the K&R oh so many years ago.
To be sure, I recognize that it’s opaque to the uninitiated, but so are let, var, &, ? and !, ->, $, [:], and a host of others. To try and eliminate all opacity would yield COBOL, or something like it.
I like the R notation, but in the end I tip towards the ternary, just because a number of languages use it, and the Swift book is free and well written.
Swift standard library operators are defined in Swift itself, using the same facilities that allow you, the user, to define your own custom operators. Implementations of standard library operator functions use the same language features that you would use for your own functions. You can read the source code for &&, for example, and understand what's going on based on your knowledge of Swift alone.
It is not possible to declare the ternary operator in Swift: there is simply no syntax to do so, and for this reason you cannot create any of your own ternary operators. You cannot read the Swift source code implementing the ternary operator ?:, because there is no such source code; you cannot even find the Swift declaration of the operator, because there is no such declaration--it cannot even be uttered.
How can a function exist without a declaration or implementation? In the parlance of the Swift project, we call this "magic." It is simply a term used to describe APIs or behaviors supported by the language where the underlying implementation cannot be accounted for purely in terms of the user-facing rules and features of Swift.
For @Hacksaw and all others interested, there was a thread a couple years back that discussed the pros/cons of the ternary operator pretty extensively: If / else expressions
The main topic (as the title suggests) was whether we should add an expression version of the if-else statement, but such a topic inevitably has to recon pretty thoroughly with the question "how is this better than the ternary operator?".
(Insert build system joke here.)