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

[Ling Wang]

> On Dec 7, 2015, at 6:21 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> 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.  
I didn’t say anything against "class methods are dynamically dispatched”. Actually my proposal states that type methods are dynamically dispatched by default.
> Similarly, we need and want “static” methods in classes for the common case in which dynamic dispatch is not desired.
I know it is for performance optimization. But why not use `final`? Also, did you read my optimization concern in this part: https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#impact-on-existing-code? <https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#impact-on-existing-code?> How do we enforce “static” dispatching for instance methods that are way more than type methods in most code?
> 
> 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.
Did you read the part about inconsistency between type and instance member declarations(https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#class-methods-vs-static-methods <https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#class-methods-vs-static-methods>) <https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#class-methods-vs-static-methods?>? What do you think about it? Do you think compatibilities with other older languages are more important than the consistencies within Swift itself?
> 
>> 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?
3. If no, then we only have one kind of type stored properties, why do we need two keywords for them?
> 
> 
>> ## 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.
As said above, I think consistencies within Swift itself are more important than compatibilities and familiarity with other languages.
> 
> 
> 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.
I know there are a lot other problems that are more urgent than what we are talking about here. But I can’t agree that the inconsistency I mentioned in this proposal is a non-problem. 
> 
> -Chris
> 

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