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

[Ling Wang]

Now I understand your concerns. But you misunderstood my proposal. I'll restate my points about “type properties”:

1. Stored class properties(let’s call them “class instance variables” for better discussion about “stored type properties” below) are not very useful or needed. So we are not likely to add them to Swift. This one we both agree. So there is only one kind of stored properties for types and they are stored like global variables, which are now called “static stored properties“. 

2. `type` properties in my proposal covers both stored properties and calculated properties. Except for the `type` keyword, the way they are declared are exactly the same as that of instance properties:
```
class Foo {
    type let i = 1 // stored type property
    type var k: Int { // calculated type property
        return 1
    }
} 
```

3. Since we’ve already excluded “class instance variables” in point 1, stored type properies in my proposal are certainly not “class instance variables”. They behave the same as the current “static stored properties”. This is where you misunderstood me. 

So you don’t need the `final` keyword to make them “static”. If they are “stored”(VS calculated) they are “static”. We just don’t use `static` as the keyword.

Static storage is the implementation details. Just like global variable declarations don’t need `static` keyword though they use static storage, stored type property declarations don’t need `static` keyword to denote they use static storage. After all there is only one kind of stored type properties.

As you said most people expect type properties to be “static”, together with the fact that most people don’t know about “class instance variables”, stored type properties being “static” is simply the commonly accepted default behavior.

As to those who know about “class instance variables” we need to explain to them that stored type properties are not “class instance variables”. But since we need to tell them that Swift doens’t support “class instance variables” at all in the first place, it is not an extra complication.

Besides, we shouldn’t use `final` to denote storage at all for `final` is about inheritability/overridability not about storage.

Thanks for discussing with me:)

- Ling

> On Dec 7, 2015, at 7:15 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Dec 7, 2015, at 5:09 PM, Ling Wang <an00na at gmail.com <mailto: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.
> 
> -Chris

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