* What is your evaluation of the proposal?
I like the general direction of more flexible property-wise initialisation however I do have some reservations about the detailed proposal, in particular:
1. You can’t initialise lets.
2. You can’t initialise more-private-stored properties than the property-wise initialiser itself.
3. You can't label property-wise initialiser arguments.
4. It is not totally clear which properties are to be initialised property-wise.
5. The proposal adds to the existing menberwise initialisers and the default initialisers; which then means there are 4 initialisers (manual, current memberwise default, and new memberwise), therefore I would prefer a proposal that encompassed all of these.
6. Super types need a default initialiser.
7. The memberwise init does not have default values for its memberwise arguments which means that all memberwise arguments need to be specified when calling the memberwise init (like current memberwise init).
8. Stored properties have to be given a default value to participate in memberwise initialisation.
9. `memberwise` isn’t a great keyword, since funcs are also members
10. The … notation can be a bit invisible.
However I think that if the design space is opened up then these issues could be addressed. Here is a modification to the existing proposal:
1. Basic example: demonstrates a short form for C-like structs and let initialisation:
// Short-property-wise form
class Size2D properties { // Note: properties keyword
let width = 0.0, height = 0.0 // Note: let
}
// Translation to long-property-wise form
class Size2D {
properties { // Note: obvious which properties are property-wise initialised
let width = 0.0, height = 0.0
} init(properties) {} // Note: placeholder, properties, for property-wise args and no init body
}
// Translation to basic Swift
class Size2D {
let width: Double
let height: Double
init(width: Double = 0.0, height: Double = 0.0) { // Note: default values for property-wise args
self.width = width
self.height = height
}
}
2. Example of how super is to be called.
// Short-property-wise form
class Size3D: Size2D properties(width: Double = 0.0, height: Double = 0.0) {
let depth: Double = 0.0
}
// Translation to long-property-wise form
class Size3D: Size2D {
properties(width: Double = 0.0, height: Double = 0.0) {
let depth: Double = 0.0
} init(properties) {}
}
// Translation to basic Swift
class Size3D: Size2D {
let depth: Double
init(width: Double = 0.0, height: Double = 0.0, depth: Double = 0.0) { // Note: super args before property-wise args
self.depth = depth
super.init(width: width, height: height)
}
}
3. More involved example with private property, properties arg label, other init, and other methods
// Only long-property-wise form allowed since other methods and other initialisers required
class LoggedAndScaledSize2D: Size2D {
properties(width: Double = 0.0, height: Double = 0.0) {
private var times scale: Double = 0.0 // Note: label, times, and private
} init(properties) {}
properties init(properties, logger: Logger? = nil) { // Note: only 1 property-wise init can have properties and super args
logger?.log(self) // Note: rest of init
}
var scaledWidth: Double { // Note: other methods
get { return scale * width }
}
// Translation to basic Swift
class LoggedAndScaledSize2D: Size2D {
private var scale: Double // Note: private
init(width: Double = 0.0, height: Double = 0.0, times scale: Double = 0.0) { // Note: label times
self.scale = scale
super.init(width: width, height: height)
}
init(width: Double = 0.0, height: Double = 0.0, times scale: Double = 0.0, logger: Logger? = nil) {
self.scale = scale
super.init(width: width, height: height)
logger?.log(self) // Rest of init
}
var scaledWidth: Double { // Other methods
get { return scale * width }
set { scale = newValue / width }
}
var scaledHeight: Double {
get { return scale * height }
set { scale = newValue / height }
}
}
4. The existing memberwise and default initialisers are deprecated.
Obviously the above is just a three examples - happy to flesh out details if there is interest.
The semantics of the proposal are as though the literal translations from short-property-wise form, to long-property-wise form, to basic Swift occurred.
The proposed semantics "as though literal translated" and previous compiler-written initialisers deprecated means that `struct Length { var length: Double = 0.0 }` is now an error - it has no initialisers. Programmer would write `struct Length properties { var length: Double = 0.0 }`, note added properties keyword.
Whether properties is much better than memberwise and … is open to some debate!
* Is the problem being addressed significant enough to warrant a change to Swift?
I think a revised proposal would be viable, but marginal as it stands.
* Does this proposal fit well with the feel and direction of Swift?
In some ways yes (because Swift has compiler written initialisation already), but in others, like adding another way of doing initialisation, no (because one aim of the evolution is not to become a ‘kitchen-sink' language like C++).
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Yes I have used a similar feature in Scala and the current proposal is much more complicated. The Scala solution seems better to me. But see proposed alternative above.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I have kept up with the discussions and have interacted with Matthew Johnston and others on this topic. I have also discussed with Bill Venners from Escalate; who is well known as an educator in the Scala community, the Scala version it is well liked in the Scala community and is easy to teach.
Glad this topic is under discussion,
-- Howard.
···
On 7 January 2016 at 09:47, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The review of "Flexible property-wise Initialization" begins now and runs through January 10th. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-property-wise-initialization.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager.
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 you 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
swift-evolution/process.md at master · apple/swift-evolution · GitHub
Thank you,
-Chris
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-- Howard.