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

[filip-sakel]

@Jumhyn

"traditional" memberwise initializer from source in Swift 6 mode—if users want that then they can specify the language mode appropriately.

I think that would create a dialect, which is unaligned with Swift's principles. I'd argue for the opposite:

1. a Swift 5 flag to opt into deprecation mode; and
2. a Swift 6 deprecation,

This is akin to Concurrency's handling of erroneous code (EDIT) in Swift 5 mode: it is permitted with an option to be warned about it.

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.

---

@Jumhyn

Of course, all the edge cases around how property wrappers interact with the synthesized initializer are already pretty complex, so I'm not eager to add a further carve-out for this case—perhaps its better to leave the current synthesized initializer as-is and go all in on the "new" initializer.

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

---

@Jumhyn

@hborla

I agree with this. If this is something folks are interested in pursuing, it feels like this is the point where someone should write up a pitch?

Once I close the loop on my previous proposal, I'd love to take a crack at writing up this pitch (but if anyone else is motivated in the meantime, don't let that stop you from getting to it first! ). This is a source of poorly-documented complexity that has always bugged me about property wrappers and I think with SE-0293 we're finally at the point where we can clean this up nicely.

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.