Inheriting from an objective-c static class in Swift

With that Obj-C declaration, the Swift version would be:

class func lineWithNumber(number:NSString)->Self

In so doing the error does not go away and a few other ones pop up saying:

Cannot convert return expression of type 'InArrivoLines' to return type 'Self'

Yes, well, Self never seems to mean what it should mean.

Can you show us the thing that's being overridden (just the function signature part, not its body), and perhaps we also need some context: some indication of the types within which both the original and overriding definitions occur?

Edit: Or better still, can you get the error into a ~10 line code fragment that we can paste into a playground?

Not very hard; this is the signature in the heading file of the Objective-c class:

+(instancetype) lineWithNumber: (NSString*)number;

As for the context, the upper class just inherit from NSObject and adopts a procol.

The Swift class just inherits from the upper class. And the signature of the allegedly corresponding function is:

override class func lineWithNumber(number:NSString)->Line

I do not think it would be so much a problem for the playground, as the issue happens at compile time, not execution time.

If only I could get the way in which Xcode exports the Objective-c heders, I would be done, but of course it seems just the reverse holds.

I didn't look closely enough at what you said originally. If the parent class declaration is bridged from Obj-C, then it should actually come into Swift like this:

class func lineWithNumber(number:String)->Self

with "String", not "NSString". That difference is enough to account for the error message.

You should provide a little more detailed context, as Swift importing strategy depends on class and method names.

If your Objective-C superclass is named as `Line` (suggested by other parts of your code, but not very clear) or NSLine, UILine, MyLine..., class methods named as `lineWith...` are imported as convenience initializers:

    public convenience init!(number: String!)

To reproduce your issue with just two lines given , readers need to guess some amount of codes, and not many would try it.

As a matter of fact I decided to painstakingly port the superclass and its gerarchy to Swift too, in order to get rid of this problem altogether; in any case I would have had to port them eventually anyway.