This is the definitional difference between an acronym and an abbreviation. And it suggests a criteria - use domain specific acronyms if they’re deeply universal, but don’t use domain specific abbreviations even if they’re commonly used in writing:
That lines up with the mental overhead model as acronyms have an identity of their own - you’re not spending any mental energy to expand them. Abbreviations on the other hand tend to be expanded by the reader when read.
It’s the difference between LASER (does anyone expand that in their head when they read it?) and NVM (which I can’t help but expand to “never mind” every time I read it).
No, @scanon just specified that ULP is read either as an acronym or an abbreviation. There is no rule in Swift against words that “expand in your head.”
In fact, the knock against “wrt” argued here is that it’s not sufficiently clear because it doesn't “expand in your head” for everyone.
Right. There’s three possibilities along the continuum:
Abbreviations people don’t know
Abbreviations they do know and tend to expand when reading
Acronyms
And no, there’s no Swift hard and fast rule here. If there were we wouldn’t be discussing it. And I’m not even suggesting that there should be a hard and fast rule. But I do think it’s worth at least thinking about a set of rough first principles as was hinted at in the OP.
And my personal feeling (which you’re welcome to disagree with) is that true acronyms are much more acceptable than common abbreviations which are more acceptable than uncommon abbreviations.
Which is why I would prefer withRespectTo rather than wrt (which is not a true acronym).
Following this thread, it seems that the attribute under consideration conveys the following information, rendered in plain English:
“This function is the derivative of < function > with respect to <parameter(s)>
I’m in the camp that would say any spelling that works against that reading is borderline wrong. Trying to sneak another preposition in place of “with respect to” renders the sentence non-idiomatic and unclear.
Using d: is pithy and cute, but ignores the way that @derivative primes you to expect English rather than math notation (and I don’t think @d is on the table as the attribute name).
I’m hesitant to weigh in on wrt: vs. withRespectTo: because I’m probably not a representative Swift user (I’m not a Swift user at all). I’m a native English speaker with a degree in math who works with academic papers regularly.
While this thread was ongoing I reviewed a (computer science) paper submission that used “w.r.t.” for “with respect to” in a context completely unrelated to differentiation. The abbreviation is a pre-existing (though not entirely common) part of academic language, whether or not that argues for its use in Swift.
Yes. When reading code out loud, an unlabeled first argument implicitly gets prefixed with “of” so that an of: label is redundant. We don’t write cos(of: x).
If I saw this without context, I would intuitively read it as "function bar with derivative foo." An of: argument label clarifies the intended meaning to "function bar, which is the derivative of foo."
Just my personal 2cts, while "wrt" is definitely English mathematical jargon (and, nowadays, mathematical research is primarily in English), it's not something that I'd expect e.g. engineering or even maths students from other countries to have seen (to me it falls in the same category as "wlog"). I certainly wouldn't know about it if I didn't sometimes watch lectures from English-speaking universities or peruse maths groups / forums on the internet.
By contrast, everyone who has done a multivariable calculus has seen the ∂/∂x notation, so IMHO d: x or something like proposed by @Nevin would be instantly recognisable unlike "wrt".
If we want to be more cutesy and verbose, I could also suggest along. This has the added bonus that, in multivariable calculus, you can't just have partial derivatives wrt. (!) specific variables, but also along arbitrary directions, which is really just a generalisation of the concept.
d: has two major problems. First it appears both above and below the line in the notation for derivative, e.g. ∂y/∂x. But there’s no way to use it like that without making something unreadable or uncompilable, e.g. derivative = d(y, d: x) or evaluate(d: y, d: x).
If you limit it just to the ∂ below the line, this is not too bad:
@derivative(of: foo, d: x, y, z)
But if foo is replaced with something more complex, e.g.
@derivative(of: armBone[1] * HandBone[1] & fingerBone[5], d: x, y, z)
it’s much harder to understand what 'd:' is on first glance. Compared to wrt: or withRespectTo: which is instantly understandable in a mathematical context.
That may be true, but Swift is a programming language based on the natural language English. English keywords are used throughout Swift’s syntax: class, for…in, try, catch, throw, override, self, return, guard, if, else, some, where, switch, case, let. Its standard library uses English-language named functions, argument labels, type names.
That said, I think we should strive to keep the language simple. But we don’t have to pretend that at least some English isn’t already a prerequisite to understand and master Swift.
And for whatever it’s worth: English isn’t my first language, although I do primarily speak a language with very few native speakers, and as such English is almost a prerequisite for any kind of academic or pop cultural engagement. Very few songs, books, movies are ever translated.
FWIW, I think there's more work to be done (though not all by the authors of the proposal in question). E.g. Xcode doesn't let you option-click on an attribute to get documentation, there should be a section on @derivative in TSPL, ...
Just found an official(?) statement with relevance for this thread (at least under its original title):
Currently diagnostic messages are only available in English which limits their usefulness to anybody who is proficient enough with the language. We’d like for people from any background to be able to learn and be productive with Swift programming language, so as a step towards this goal, compiler should be able to produce diagnostic messages in any language familiar to the user.
I have to admit that I'm a little bit skeptical about translated messages, though (there should at least be a unique identifier which is identical for all languages for each error or warning…).