I'm building a linux Path library that wraps the Glibc APIs (rather than using Foundation.FileManager which isn't fully implemented on Linux).
I'm receiving an error I don't understand though:
public class AbsolutePath: RelativePath {
// cannot override non-throwing initializer with throwing initializer
public convenience init(_ path: Path) throws {
self.init()
self.path = try AbsolutePath.expand(path)
}
The parent class RelativePath
has the following initializer which is causing the collision:
public class RelativePath: Path {
public convenience init(_ path: Path) {
self.init(path.string)
}
}
I don't understand why this is causing the collision though. Aren't convenience initializers specific to that class? They can't be overridden in subclasses anyways so why can't I write a new convenience initializer with a different signature?
The root Path
class has the following initializer:
public class Path {
public convenience init(_ path) {
self.init(path.string)
}
}
I don't get an error in the RelativePath
when I declare the convenience initializer with the same signature. I don't have to use the override
keyword because I'm not overriding anything since they're all convenience initializers.
If I add the override
keyword to my convenience initializer I receive an error that I would expect to see:
public class AbsolutePath: RelativePath {
// initializer does not override a designated initializer from its superclass
public override convenience init(_ path: Path) throws {
self.init()
self.path = try AbsolutePath.expand(path)
}
I've looked through Apple's documentation about initializers (specifically the section titled "Class Inheritance and Initialization") and I can't seem to find any reasonable explanation for why I would be receiving this sort of collision when I'm using convenience initializers.
It would make sense if they were designated initializers, and that's actually why I switched to convenience initializers in the first place! I wanted to override in AbsolutePath
with throwable initializers but didn't want/need to make the RelativePath
and Path
ones also throwable.
Does anyone know or understand why this is happening? Or is this a Swift bug?