Compiler crashes during type checking when using protocol and associated type #62219
Comments
zdtorok
added
the
bug
AnthonyLatsis
added
compiler
|
Reduced: protocol P {
associatedtype A
var s: [A] { get set }
}
var p: any P
let s = p.sWe should be we rejecting this: SE-0309 is not implemented for settable storage requirements yet. You can work around it with a protocol extension: extension TestDelegate {
func removeAllActions() {
self.actions.removeAll()
}
} |
AnthonyLatsis
added
the
existentials
|
Thanks, your workaround seems to work, but what if I have to e.g. insert a new element into this array? Like the following: protocol ActionType {
associatedtype T
var value: T? { get set }
}
protocol P {
associatedtype AType: ActionType
var actions: [AType] { get set }
func removeElements()
func addElement(_ action: AType)
}
class ActionTypeImpl: ActionType {
typealias T = Int
var value: Int?
init(value: Int? = nil) {
self.value = value
}
}
class PImpl: P {
typealias AType = ActionTypeImpl
var actions: [ActionTypeImpl] = []
func removeElements() {
actions.removeAll()
}
func addElement(_ action: ActionTypeImpl) {
actions.append(action)
}
}
class TestClass {
var pImpl: (any P)?
}
let testClass = TestClass()
testClass.pImpl = PImpl()
testClass.pImpl?.removeElements() // <-- This works
let newAction = ActionTypeImpl()
testClass.pImpl?.addElement(newAction) // <-- Member 'addElement' cannot be used on value of type 'any P'; consider using a generic constraint insteadWith |
|
class TestClass<T: ActionType> {
var pImpl: (any P<T>)?
}Note that this is a new feature that requires runtime support and it may not suit your deployment target. Though, is the regular generic approach not an option in your case? class TestClass<T: P> {
var pImpl: T?
}This is a tricky and subtle topic, so feel free to ask questions! |
|
Thank you for your explanation. This constrained existential might work for my case, but after some rework of our code, it came out that we could simplify it, so at the end this level of abstraction was not needed anymore. |
|
Good to hear! This kind of abstraction often tends to be the wrong answer. |
AnthonyLatsis
added
swift 5.9
existential member accesses
…rased result type - Fixes swiftlang#62219 - Fixes swiftlang#60619, - Fixes rdar://104230391 - Fixes rdar://118247162.
…rased result type - Fixes swiftlang#62219 - Fixes swiftlang#60619, - Fixes rdar://104230391 - Fixes rdar://118247162.
…rased result type - Fixes swiftlang#62219 - Fixes swiftlang#60619, - Fixes rdar://104230391 - Fixes rdar://118247162.
|
This either regressed or was accidentally closed. Edit: Ah, no, it just stopped crashing for a while, but has never errored out, which is what it is supposed to be doing. |
AnthonyLatsis
added
swift 6.0
assertion failure
|
Yep, have definitely run into this problem with swift 6. Will look at refactoring my code :) |
Description
Compiler crashes during type checking when using protocol and associated type. Xcode gives no errors or warnings on the source code.
The following code will reproduce the issue:
The stack dump:
Steps to reproduce
Simply compile the above code from command line or in a playground/Xcode.
Expected behavior
I would expect that the compiler deducts the type of
testDelegate?.actionsproperly and the code builds without errors.Environment
swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51)
Target: arm64-apple-macosx13.0
The text was updated successfully, but these errors were encountered: