[swift-evolution] Unify `static` and `class` keywords

[Chris Lattner]

On Dec 7, 2015, at 8:13 AM, an0 via swift-evolution <swift-evolution at swift.org> wrote:
> The coexistence of `static` and `class` keywords for declaring type
> properties and methods is confusing and causes inconsistency between
> type and instance member declarations. This document reasons why we
> don’t need both and suggests we unify them with a better keyword
> `type`.

I’m sure you know this, but for folks who haven’t dug through the history, the design team has already implemented, evaluated and rejected this idea.  We have also spent a lot of time over the years discussing and debating the issue, and have come to the current approach.  Since the Swift 1.2 changes went in, we haven’t seen significant confusion.

> #### Class stored properties VS. static stored properties
> 
> If you use the `class` keyword to declare a stored property in a class
> you will get this compiling error:
>> class stored properties not yet supported in classes; did you mean 'static'?
> 
> So what are class stored properties? How are they different from
> static stored properties?

This is a well-defined concept that comes from the Objective-C language, where class methods are dynamically dispatched.  We are not willing to sacrifice compatibility with this concept.  Similarly, we need and want “static” methods in classes for the common case in which dynamic dispatch is not desired.

Further, the current Swift design works well for folks more familiar with Java or C++ object models can just ignore class methods and use static methods.  They behave pretty much as they would expect.

> Class stored properties VS. static stored properties


You list many complaints about class properties, then go on to suggest that we replace “class” with “type”.  It seems that your complaints aren’t actually relevant to the proposal, since you’re not actually removing them from the model.  In fact, instead of “static var x” you’d have to write “final type var x”, which would be an unfortunate regression.


> ## Proposed solution: type.

This sacrifices all familiarity for folks coming from other extended C-family of languages, is not precedented in a popular language that I’m aware of, and is an unfortunate word to take as a keyword.

Beyond that, what you’re attempting to address is pretty much a non-problem.  I’m aware of a lot of problems with Swift :-) but I have never seen the Swift 1.2+ design cause practical problems.

-Chris