[awaiting evolution] Allow convenience initializers to reassign self. #19311
Conversation
|
@swift-ci Please test |
|
Build failed |
lib/AST/ASTContext.cpp
Outdated
| @@ -3098,7 +3098,7 @@ AnyFunctionType::Param swift::computeSelfParam(AbstractFunctionDecl *AFD, | |||
|
|
|||
| if (auto *FD = dyn_cast<FuncDecl>(AFD)) { | |||
| isStatic = FD->isStatic(); | |||
| isMutating = FD->isMutating(); | |||
| isMutating = FD->isMutating() && !containerTy->hasReferenceSemantics(); | |||
There was a problem hiding this comment.
This is unnecessary because isMutating() will never be true for a class method.
There was a problem hiding this comment.
I’ll change it to an assertion.
| if (!containerTy->hasReferenceSemantics()) { | ||
| isMutating = true; | ||
| } else if (Ctx.LangOpts.isSwiftVersionAtLeast(5) | ||
| && !CD->isDesignatedInit()) { |
There was a problem hiding this comment.
Would it be clearer to say CD->isConvenienceInit()?
There was a problem hiding this comment.
If we ever expose factory inits as a user facing feature, they’d have the same behavior, wouldn’t they?
| isInout = true; | ||
| // The `self` parameter of convenience initializers is considered 'inout' | ||
| // for semantic purposes in the AST, but at the ABI level is always | ||
| // passed by value in and returned out. |
There was a problem hiding this comment.
We'd only end up here when computing the lowered initializing entry point type right? In which case this check should not matter since we only do this for designated inits.
There was a problem hiding this comment.
Convenience inits still have initializing entry points for ObjC interop. This is necessary so that the lowering for the ObjC thunk still works.
|
Build failed |
Now that convenience initializers are implemented exactly the same as value type delegating initializers, it's straightforward to allow them to assign self to an existing object reference instead of only allowing them to chain to other initializers. Because convenience inits can be inherited, the formal type of self is still the dynamic Self type, however. This was handled unsoundly in Swift 4 mode, and unfortunately we can't fix it without breaking source in Swift 4 mode, so enable this feature only in Swift 5 mode. Making `self` inout inside convenience inits also changes the code generation of loads from self, so we need to tweak DI's special handling of type(of: self) slightly so that it also recognizes this new pattern.
jckarter
force-pushed
the
assigning-convenience-inits
branch
from
12a5139 to
26349dc
Compare
CodaFi
added
the
swift evolution pending discussion
|
@jckarter I noticed you closed the evolution PR. Do you want this open too? |
|
Sure, we can reopen it when we start actively working on it again. |
|
So, is this a dead evolution? There's plenty of people still waiting for this. |
Now that convenience initializers are implemented exactly the same as value type delegating initializers, it's straightforward to allow them to assign self to an existing object reference instead of only allowing them to chain to other initializers. Because convenience inits can be inherited, the formal type of self is still the dynamic Self type, however. This was handled unsoundly in Swift 4 mode, and unfortunately we can't fix it without breaking source in Swift 4 mode, so enable this feature only in Swift 5 mode.
Making
selfinout inside convenience inits also changes the code generation of loads from self, so we need to tweak DI's special handling of type(of: self) slightly so that it also recognizes this new pattern.Proposal: swiftlang/swift-evolution#910