When initializing a data structure (struct & class) with named fields, allow writing propertyName as a shorthand for self.propertyName = propertyName . This allows a compact syntax for initialization, with less duplication.
Example:
struct Point {
let x: Int
let y: Int
init(x: Int, y: Int) {
self.x = x
self.y = y
}
}
For now we can't write .init() like this:
struct Point {
let x: Int
let y: Int
init(x: Int, y: Int) {
x; y
}
init(x: Int, y: Int) {
x
y
}
}
Because the parameter names and the struct field names are exactly the same.
If the init is that simple, it can be omitted. If you need a different access level, you should try and revive the pitch from a while back to allow synthesized init with access levels other than internal.
If that syntax would be interspersed with other logic, I'm a huge no way. That syntax is already legal, though you'll get a warning for an unused value. Giving it a brand new meaning inside of init would be terribly confusing. There's also no indication that assignment is being done.
Yes, but you cannot mix it with non-autoassigned parameters. Also doesn‘t work with classes and you cannot run code after the assignments in the init method (I think).
I think the justification from writability (how annoying it is to type all this stuff out manually) is very weak, because it's likely that you only have to do this once, when first declaring the struct. For a developer, some days are just more boring than others.
A justification from readability might carry more weight (because the code is likely to be read a lot more often it's written), but in this case I think readability suffers, because the proposed syntax is so contextual. Bulky though it is, you can't say that this sort of thing isn't crystal clear:
init(x: Int, y: Int) {
self.x = x
self.y = y
}
However, I think a better solution is to make this a behavior of Xcode and IDEs, where they would retrieve the synthesized text (of an omitted initialization) from the compiler, and use that to provide fixits for properties that were not initialized before the end of the init. This would be roughly similar to the IDE adding stubs for missing protocol conformances.
That approach would also tie into a larger discussion about "instantiating" synthesized code in general. There are a few places we'd like this, including Codable conformance, to take a very obvious example.
One thing to consider is that it's not only a tax on writing, but also on renaming properties. So a result of this redundancy is that properties may be named less optimal (on average) than they would be if renaming them was less work.
which is sugar for self.propertyName = propertyName
and only works within an init statement (presumably)
Just feels too unseen-magic-y. I also feel like this syntax starts to become a lot less clear when you have to do some processing within the initializer. For example,
struct Person {
let name: String
let occupation: String?
init(firstName: String, lastName: String, occupation: String?) {
self.name = firstName + " " + lastName
occupation
}
}
The case above is already quite simple, but I feel like it demonstrates how unclear this could end up being in a larger example since there is no indication of assignment at all.
The problem that this seems to address is making member wise inits easier to create - like Charles_Constant has said, the only reason I see this being necessary is if you need to make the member wise initializer public, or if you have multiple initializers and want one of them to be the member wise one.
While I appreciate the motivation behind simplifying initializers, I personally don’t believe this new syntax improves clarity or reduces meaningful complexity.
The current self.x = x form is explicit, readable, and beginner-friendly. It makes the relationship between parameters and stored properties immediately clear, especially to developers who are just starting with Swift or coming from other languages. Introducing a more implicit shorthand like:
init(x: Int, y: Int) {
x
y
}
may save a few keystrokes, but at the cost of readability and learnability. It introduces an abstraction that isn’t immediately obvious.
