Does the new Swift 5.5 init(projectedValue:) functionality not work with synthesized memberwise initializers?

[Jumhyn (Frederick Kellison-Linn)]

@filip-sakel

I think that would create a dialect, which is unaligned with Swift's principles.

@filip-sakel

I think keeping around both inits is preferable given Swift's source-compatibility constraints.

I'm not sure how this would be different than any other source-breaking change that we've adopted across a major language version bump. The rule would just be "in Swift version <6, we use the 'legacy' memberwise init synthesis algorithm, in Swift version >=6 we use the 'new' one."

@filip-sakel

This is akin to Concurrency's handling of erroneous code: it is permitted with an option to be warned about it.

Perhaps I'm out-of-date on the latest Concurrency plans, but I thought this characterization only applied to code in the Swift 5 language version:

@Douglas_Gregor

A compiler option ( -warn-concurrency ) will be provided to warn about Swift 5 code that will be invalid under the Swift 6 rules.

That is, in Swift 6 we will start emitting errors for code that would compile fine (with an optional warning) in the Swift 5 language mode.

@filip-sakel

To further ease migration, we could also soft-deprecate traditional inits in Swift 5. That is, we wouldn't suggest them in auto-completion, while keeping them valid and warning-free.

Yeah, this would be great. We'd need to make sure there's always a way for users to disambiguate between the two inits in cases where they might be ambiguous, though .

@filip-sakel

I'd love to write a pitch for this! When you are ready, or if anyone else is interested, feel free to DM me.

EDIT: Along with a new init for wrapped properties, we could completely overhaul wrapper-related initialization with projection-based wrapped-property initialization.

Will do! Personally, I think these should be two separate proposals, with the memberwise init proposal also encompassing any other 'fixes' we want to make to the synthesized init (potentially unrelated to property wrappers, even if that's the main motivation).