However, during review an enhancement to the proposal was suggested: that Integer generic parameters should become static constant members of the type. This has been added to the proposal – a diff can be found here.
A focused review of this amendment begins now and runs through the 14th January.
Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
This is a great update. Given that the values and names are available even without the implicit static members, adding them as part of the initial feature avoids setting up potential source breakage if we were to do it later.
So what happens in the case where a generic parameter name conflicts with an inherited property name?
class Parent {
// This property may have been added after Child was written,
// because adding a static property is an ABI-stable change.
static let foo: Int
}
class Child<let foo: Int> : Parent {
// Does Child’s foo shadow the one inherited from Parent?
}
Swift errors today if Child first has a static property foo: Int and then you add such a property to Parent, so it should do exactly the same thing here with your example.
I think the overarching principle here is that every integer generic parameter behaves exactly as though it's also declared as a static member.
What happens at runtime if the dynamically-linked module containing Parent is newer than the one containing Child? In other words, if I compile Child against a .swiftmodule whose Parent does not contain a definition of foo, but then run that code on a system where Parent does have a definition of foo, is my Child’s static foo getter called by any code that treats my Child as a Parent? Does the answer to that depend on whether Child itself has been compiled with ABI stability?
Big +1 to these being automatic. It’s unfortunate Swift 6 shipped already, otherwise that could have been the opportunity to enable the same functionality for types in general, but perhaps it can be automatic as an internal type alias that can be overridden or declared public manually, in line with automatic conformances and inits in general? If that is the case, it would make sense for these to also be internal by default, and allow for an override to mark them public for consistency.
I think the answer is no to both, but would be good to confirm the answer empirically. Whatever already happens with static properties on Child and Parent, my understanding of this amendment is that it doesn't touch any of that.
This question is not really related to this proposal. It's a general question about how Swift behaves. The same behavior would apply about this synthesized property as to one that was manually-written.
