You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
swift-ci opened this issue
Jan 8, 2019
· 0 comments
Labels
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselffeatureA feature request or implementation
As I understand it, there are two ways for an initializer that delegates to a failable initializer to react to the delegated initializer failing.
If the delegating initializer is nonfailable, then it must call the other initializer with a trailing "!" to cause a crash if it fails.
If the delegating initializer can fail, it can call the other initializer without any suffix and the system will make sure the outer initializer will pass on the inner's fail-ness if that occurs.
There doesn't seem to be a way for the outer initializer to test that the inner one failed and carry out some other policy, like throwing an error. I don't know if there's any other solutions beside throwing an error. (You could re-evaluate another value with another initializer call, but we may want to limit the number of delegated initializer calls to one.)
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselffeatureA feature request or implementation
Additional Detail from JIRA
md5: 3647163ac6c28a30a45a7be03b2abb49
Issue Description:
As I understand it, there are two ways for an initializer that delegates to a failable initializer to react to the delegated initializer failing.
If the delegating initializer is nonfailable, then it must call the other initializer with a trailing "!" to cause a crash if it fails.
If the delegating initializer can fail, it can call the other initializer without any suffix and the system will make sure the outer initializer will pass on the inner's fail-ness if that occurs.
There doesn't seem to be a way for the outer initializer to test that the inner one failed and carry out some other policy, like throwing an error. I don't know if there's any other solutions beside throwing an error. (You could re-evaluate another value with another initializer call, but we may want to limit the number of delegated initializer calls to one.)
There's more information at a thread I created before this.
The text was updated successfully, but these errors were encountered: