Why isn't `extension` abbreviated `ext`?

Using Swift
1

Given we have other shorter versions of words, like func for function and var for variable, I'm wondering why extension isn't written as ext.

I believe with Swift pushing for using extensions as much as possible, it should be quick and easy to write them without incurring too much code noise, so this shortening would help a lot towards this.

A potential answer that comes to mind is that when Swift was introduced, extensions were quite a new things across the community, so ext might've thrown some people off when adopting the language whereas func and var are commonly known, intuitive words even across other languages. If so... after 5 versions of Swift and an ever growing community, is it time to consider introducing this change into the language?

I'd love to hear everyone's thoughts on this.

2

I'm a fan of using the full word. It seems that Swift usually favours clarity over brevity (within reason), and I like that feature of the language.

func and var are a different case, because they might appear dozens of times within a source file. Abbreviating extension is going to save far less typing overall, but it is going to make your code less readable.

6 Likes
3

I'm negative on this. Firstly, because I don't want to have two keywords for the same feature, and we're already stuck with extension. But secondly, even if we were to design this from scratch I don't think I would have preferred ext over extension simply because it is too short. var and func has ample prior art in computer programming, and I don't expect anyone to be confused about their meaning. However, in C we have extern which may cause confusion.

We also have public not pub, private not priv, internal not int or intern, etc.

10 Likes
4

Thank you for your response guys! You changed my mind about this, especially with public, internal, private — and specially fileprivate — being a thing.

2 Likes
5

extension comes from Obj-C and existed long before Swift. Abbreviations can cause confusion. The Swift API docs suggest not using abbreviations. But that's for variable and type names. Frankly var and func are the odd men out.

6

I prefer func to be function for clarity. Also typealias to be just type because most of the time typealias is a complete new data type.

For example, typealias Handler<T> = (Result<T>) -> Void is not mere an alias.

But there’s nothing we can do at this point. So, it is what it is.

7

How do you mean? typealias by definition defines a new name for the same type, but they are otherwise identical to the compiler. Any value of type (Result<T>) -> Void can be used where Handler<T> is expected and vice versa (because they are the same type).

1 Like
8

It's really not a new type. All the extensions from one applies to another. It truly is an alias.

1 Like
9

If we really wanted to optimise for brevity, we could just call it an alias. Maybe we could also allow it to support functions, too.

In general I wouldn’t mind a shorter way to write extensions, if it helped explain the concept better than the existing keyword.

I could imagine something like:

struct MyStruct { ... }

+++ MyStruct {
  func myExtensionFunc() { ... }
}

It might kind of look confusing in textual diffs, though.

10

Or even…

struct MyStruct { ... }

func MyStruct.myExtensionFunc() { ... }

I think Kotlin allows something like this.

1 Like
11

extension comes from Obj-C and existed long before Swift.

While the concept comes from Objective-C, the behaviour of Swift extensions more closely matches a category than a class extension. To quote Programming with Objective-C:

A category can be declared for any class, even if you don’t have the
original implementation source code …

… it’s not possible to declare an additional instance variable in a
category …

A class extension bears some similarity to a category, but it can only
be added to a class for which you have the source code at compile time
…

Unlike regular categories, a class extension can add its own
properties and instance variables to a class.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

4 Likes
12

One thing I’ve wanted, but haven’t yet proposed on Swift Evolution, is the ability to define identifier aliases, which would give a convenient short local name to something that would otherwise have to be repeated multiple times in full. For example:

alias currentSlice = someArray[rangeOfInterest]
currentSlice.sort()
someMutatingFunction(&currentSlice)
currentSlice.reverse()
// etc.

This is different from declaring a variable (eg. “var temp = ...”), because it does not change any reference counts, and mutation still goes through the original storage.

This is different from #define because it is strictly available for aliasing one identifier to another. It does not allow arbitrary textual substitution in source code.

This is different from key-paths because the alias can be used directly as an identifier.

This is different from reference semantics, because passing the alias to a function will pass the instance by value, exactly as if you had called the function with the original variable.

It is purely and exclusively an alias for an identifier. Its only purpose and effect is to create a new name for an existing thing, just like a typealias does for types.

And when working with mutating algorithms on slices of collections, that can be extremely convenient.