Explicit Swift Keywords

  • Proposal: SE–####
  • Author: @Nevin
  • Review Manager: TBD
  • Status: Ready for immediate widespread adoption


Swift strives to have clear, explicit, and readable APIs, prioritizing clarity at the point of use ahead of brevity. This is one of the many features which make Swift a broadly enjoyable and accessible language.

When the API Design Guidelines were adopted in Swift 3, many functions in the standard library were renamed to increase consistency and comprehension. Keywords, however, were not given the same treatment, and many of them are still spelled with abbreviations and awkward juxtapositions.

This proposal aims to make Swift keywords explicit.


Many Swift keywords are English words with existing meanings similar to or reminiscent of their usage in Swift. However, some keywords are abbreviations, such as:

func, var, struct, enum, init, deinit

And other keywords consist of two words stuck together with no distinguishing separator, including:

associatedtype, fileprivate, inout, fallthrough, precedencegroup, typealias

These are all potentially unfamiliar and non-obvious to readers, which contravenes the goal of Swift being easy to learn and understand.

Proposed solution

We aim to fix this shortcoming, so that declarations and other uses of keywords will line up with the way people speak in their everyday lives. The increased familiarity should help Swift become more widely adopted.

In order to accomplish that goal, we propose that Swift keywords should be made explicit.

Now, to be abundantly clear, when we say “explicit”, we are emphatically not proposing to replace existing Swift keywords with profanity. That is ridiculous. For one thing, it would be massively source-breaking. It’s a non-starter, no matter how good of an idea it might be.

No, what we propose is in fact the exact opposite of that:

Existing Swift keywords should start being used as profanity in everyday language.

Detailed design

The community will shape the design of this feature through direct usage. The proposal itself simply offers some recommendations and suggestions. To help get everyone started, here are a few examples of how Swift keywords can be used explicitly:

“Frankly my dear, I don’t give enum.”

“Place got hit by lightning, huh? func you, pay me.”

“You maniacs! You blew it up! deinit you! deinit you all to nil!”

“Enough is enough! I have had it with these fileprivate snakes on this fileprivate plane!”

Source compatibility

This is an additive, source-compatible change to the English language. Furthermore, that language has not yet achieved a stable version number and is in constant flux, so its practitioners are already accustomed to learning new words and changing definitions. We do not forsee any problems on this front.

Alternatives considered

It is also possible to use existing Swift keywords as incisively biting takedowns which are not technically profane. We leave this as an exercise for the reader. The reader with true class that is, not the super lazy one.


I though this was cancelled. func should have been fun.

I like it, even if the justification is a bit weak :stuck_out_tongue:


Yo mamma so fat, she fallthrough a guard.


func this, I'm out. :bear:

Are we doing april first gags now?

1 Like

Now? It's been like this for years. ;)

1 Like

You mean "It's been like this for years"? :3


Thanks that you repeat my incorrect wording.

1 Like

It's just something to do while we are discussing new keywords.

guard thy self! defer from such false claims!
where for dost thou repeat that lazy #line?

do switch the public taunt for private jest,
else thy unowned #error shall infix

upon thy case where Any one can see
and let thy #colorLiteral show true.


One consideration that others seem to have missed: will this proposal support backwards-deployment to improve the quality of old literature?