Repository navigation
Deprecated variables used in generated inits, could the init be marked deprecated as well? #932
Description
Question
When a struct includes a deprecated variable, the generated variable correctly gets a @available(*, deprecated) notation. However, the struct also gets an autogenerated init which uses this deprecated variable, and is not itself marked as deprecated, thus generating a workspace-wide warning message.
I was initially hoping you could just autogenerate a pragma silence to the specific line in the init that uses the deprecated value, but I now realize it's not possible to do so in Swift.
However - if the entire init is marked as deprecated, it would silence the use within.
I don't know, maybe this just moves the problem elsewhere, or maybe it's better with one deprecated init (including all deprecated variables) and one non-deprecated init that just omits the deprecated variabels and just don't set them (as long as they are optional, I think they should implicitly resolve to nil without warnings?)
I'm not sure what's best, I'm just sad about the warnings we're getting.
Activity
czechboy0 commentedon Aug 6, 2026
Hi @StianFlatby,
yeah this is a genuine problem.
Some sort of two variants of inits, one with all properties, one with only non-deprecated properties would be doable, I agree.
However, I'm also not sure what we'd do about deprecated required properties.
KyawTheMonkey commentedon Sep 18, 2026
Hi @czechboy0, I’d love to take this on and put together a PR for it. Just wanted to check if anyone is currently working on it, if not, could you please assign it to me?
czechboy0 commentedon Sep 18, 2026
Hi @KyawTheMonkey,
before you spend time on the PR, can you first outline your approach?
KyawTheMonkey commentedon Sep 19, 2026
Sure @czechboy0. Here's what I thought.
If there are no deprecated properties, the output remains unchanged. The majority of documents will be untouched.
If all deprecated properties are omitable (i.e., optional or carrying a schema default), we emit two initialiser variants
A deprecated property that is non-optional but carries a schema default must be assigned directly at the property declaration so the clean initialiser can omit it.
If there is at least one deprecated required property (regardless of any deprecated optional properties), we emit only the full initialiser, marked as deprecated. A clean initialiser cannot be provided here, as a value must still be supplied for the required field. Marking this sole initialiser as deprecated makes it explicit that the type cannot be constructed without touching a deprecated field. This still resolves the original issue by shifting the compiler warning out of the generated code and onto the adopter's call site, where they can address it.
Anyone building with warnings-as-errors and passing a deprecated argument would newly fail. Would you prefer this behind a flag for a release or two, or is a 1.x minor acceptable given nothing stops compiling?
Happy to adjust any of the above before I write the PR.
czechboy0 commentedon Sep 19, 2026
So currently we don't generate defaults, that's tracked by #66