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

Chris Lattner clattner at apple.com
Mon Dec 7 19:15:33 CST 2015

> On Dec 7, 2015, at 5:09 PM, Ling Wang <an00na at gmail.com> wrote:
>>> 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.
> When you said "You list many complaints about class properties” you meant “class stored properties”, right?
> If so I don’t think I’ve ever complained about it because Swift doesn’t support class stored properties yet. My points about class stored properties are:
> 1. Are they useful enough? Do we want it in Swift?
> 2. Are we going to add it in Swift? If yes, when?

Perhaps, but they are very low priority. 

> 3. If no, then we only have one kind of type stored properties, why do we need two keywords for them?

You’re missing what I’m trying to say.  With your design:

class Foo {
  type var x : Int

This would be a stored class property, which isn’t supported and won’t be for the forseeable.  This would require people to write:

class Foo {
  final type var x : Int

This is a lot worse than:

class Foo {
  static var x : Int

... both in terms of boilerplate noise, but also in that it leads them down the wrong path.  Many people would write “type var x : Int” wanting a static member, because they don’t understand how class variables work.

Your approach would make class members *more* prominent, not less.  We’ve tried this, this is not a theoretical concern.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/5b6267a9/attachment.html>

More information about the swift-evolution mailing list