[SR-7111] Class function override T?? to T.

[tarunon]

Resolves SR-7111.

[slavapestov]

I’d rather we didn’t make this change. Ideally method override matching would use the same logic as the type checker’s subtype relationship. But in the absence of that, just adding new special cases is probably not a good idea.

[jrose-apple]

Override matching is already a different thing than subtypes, and I think the point is that this isn't a new special case; it's fixing the logic for an existing special case. FWIW this is already a reusable API, TypeBase::matches.

[slavapestov]

My point is exactly that the only reason override matching is different than subtyping is historical accident, and we should either leave it alone or combine the two.

[tarunon]

I think Differences is not historical accident, maybe it is about Existential.

protocol Animal {}
class Cat: Animal {}

class Foo {
    func get() -> Animal { fatalError() }
}

class Bar: Foo {
    override func get() -> Cat { fatalError() }
}

It seems be compile error today, can we solve it already? If my memory is correct, it was rutime error.

[slavapestov]

@tarunon This example could be made to work pretty easily I think. SILGen can already emit the right thunk there because it supports all subtype conversions — what’s missing is the type checker admitting this case as an override. But my point is that it would be better in the long run to actually use the same code we use when solve subtype constraints, instead of using bespoke code to match overrides.

[slavapestov]

@rudkx might have some ideas, I think this might be related to his Type::join work.

[rudkx]

There is definitely non-accidental history behind why we cannot just test subtyping here.

We allow overriding Objective-C methods that take unaudited pointer arguments (imported as IUOs) with Swift methods that take non-optional arguments.

There may be other reasons as well.

[rudkx]

Can you please add tests for things which should not be allowed as well?

[tarunon]

I know the various problems that optional covariances, I think T to T? subtyping should be abolished, but I also understand it is necessary for compatibility with Objective-C. Perhaps it is better to allow optional covariances in only @ objc attribute. I would like to discuss it in the swift-evolution.
I tried to generalize Optional's subtyping according to the current subtyping rule in this PR. If we need a big modification (such as merging common subtyping and override), I think it would be better to discuss in swift-evolution.

[tarunon]

BTW, I try to using common subtyping way in this week end. @slavapestov

[tarunon]

I add property test cases, it should be failure case. Can I add other test cases? @rudkx
I try to use swift::TypeChecker::isSubtypeOf instead of swift::type::matches, it seems work well(also Existential case).

[rudkx]

@tarunon When you say that using isSubtypeOf works well, what tests did you run?

I would expect that to fail for the cases I already mentioned regarding the special-case for overriding unaudited Objective-C methods.

[tarunon]

I replace matches to isSubtypeOf in this line, and every test cases was passed.

swift/lib/Sema/TypeCheckDecl.cpp

Line 6402 in 72e4224

if (!propertyTy->matches(parentPropertyTy,

But I found 1 more use matches at this line,

swift/lib/Sema/TypeCheckDecl.cpp

Line 6155 in 72e4224

if (declFnTy->matchesFunctionType(parentDeclFnTy, matchMode,

I think I should add some of implements for these if we use isSubtypeOf

[tarunon]

I close PR cuz I can't see long time 😞
If I can, try make PR again 🧐