Superclass constraint cannot depend on type parameter

Jon_Shier · 2016-03-09T20:48:50.000Z

Swifters:
I just encountered the error “Superclass constraint ‘RepeatableNetworkOperation’ cannot depend on a type parameter” on this definition:

class RepeatedNetworkOperation<T, U where U: Decodable, U == U.DecodedType, U: Repeatable, T: RepeatableNetworkOperation>: RepeatedOperation<T> { … }

where the relevant other classes are defined as:

class InterruptibleNetworkOperation<T: Decodable where T == T.DecodedType>: GroupOperation { … }
class RepeatedOperation<T where T: NSOperation>: GroupOperation { … }
class RepeatableNetworkOperation<T where T: Decodable, T == T.DecodedType, T: Repeatable>: InterruptibleNetworkOperation<T>, Repeatable { … }

I understand the error, but am I correct in thinking this is just a limitation of Swift’s current type and/or generics systems? I’m not a language theorist, but it seems perfectly reasonable that something like this should work. If it is just a limitation and not something I’m doing wrong, are there any suggestions for a workaround? The class I’m trying to write would really clean up my code.

Jon

Slava_Pestov · 2016-03-17T17:01:32.000Z

Hi Jon,

You are right that this is a limitation of the current implementation in Swift 2.2. I may have fixed this recently in master:

github.com/apple/swift

ArchetypeBuilder: Allow generic signature superclass constraints to contain type parameters

committed 07:23AM - 12 Feb 16 UTC

slavapestov

+86 -31

There was a diagnostic to catch these, but it wasn't triggered reliably, and it …sounds like users were already relying on this feature working in the few cases where it did. So instead, just map an archetype's superclass into context when building the archetype. Recursion is still not allowed and is diagnosed, for example <T, U where T : C, U : C<T>>. Note that compiler_crashers_fixed/00022-no-stacktrace.swift no longer produces a diagnostic in Sema, despite the fact that the code is invalid. It does diagnose in IRGen when we map the type into context. Diagnosing in Sema requires fixing the declaration checker to correctly handle recursion through a generic signature. Right now, if recursion is detected, we bail out, but do not always diagnose. Alternatively, we could prohibit unbound generic types from appearing in generic signatures. This is a more principled fix for rdar://problem/24590570.

It would be great if you could try the latest compiler with your code.

Slava

···

On Mar 9, 2016, at 12:48 PM, Jon Shier via swift-users <swift-users@swift.org> wrote:

Swifters:
I just encountered the error “Superclass constraint ‘RepeatableNetworkOperation’ cannot depend on a type parameter” on this definition:

class RepeatedNetworkOperation<T, U where U: Decodable, U == U.DecodedType, U: Repeatable, T: RepeatableNetworkOperation>: RepeatedOperation<T> { … }

where the relevant other classes are defined as:

class InterruptibleNetworkOperation<T: Decodable where T == T.DecodedType>: GroupOperation { … }
class RepeatedOperation<T where T: NSOperation>: GroupOperation { … }
class RepeatableNetworkOperation<T where T: Decodable, T == T.DecodedType, T: Repeatable>: InterruptibleNetworkOperation<T>, Repeatable { … }

I understand the error, but am I correct in thinking this is just a limitation of Swift’s current type and/or generics systems? I’m not a language theorist, but it seems perfectly reasonable that something like this should work. If it is just a limitation and not something I’m doing wrong, are there any suggestions for a workaround? The class I’m trying to write would really clean up my code.

Jon

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Jon_Shier · 2016-03-17T17:42:23.000Z

Slava:
I won’t be able to test my actual code, as the Operations and Alamofire libraries haven’t been updated for Swift 3 (which I wouldn’t expect), but I’ll try to put together a test cast that is similar and see if it works? When will this change be part of the package I can download for Xcode 7.3?

Jon

···

On Mar 17, 2016, at 1:01 PM, Slava Pestov <spestov@apple.com> wrote:

Hi Jon,

You are right that this is a limitation of the current implementation in Swift 2.2. I may have fixed this recently in master:

ArchetypeBuilder: Allow generic signature superclass constraints to c… · apple/swift@3aacf5d · GitHub

It would be great if you could try the latest compiler with your code.

Slava

On Mar 9, 2016, at 12:48 PM, Jon Shier via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

Swifters:
I just encountered the error “Superclass constraint ‘RepeatableNetworkOperation’ cannot depend on a type parameter” on this definition:

class RepeatedNetworkOperation<T, U where U: Decodable, U == U.DecodedType, U: Repeatable, T: RepeatableNetworkOperation>: RepeatedOperation<T> { … }

where the relevant other classes are defined as:

class InterruptibleNetworkOperation<T: Decodable where T == T.DecodedType>: GroupOperation { … }
class RepeatedOperation<T where T: NSOperation>: GroupOperation { … }
class RepeatableNetworkOperation<T where T: Decodable, T == T.DecodedType, T: Repeatable>: InterruptibleNetworkOperation<T>, Repeatable { … }

I understand the error, but am I correct in thinking this is just a limitation of Swift’s current type and/or generics systems? I’m not a language theorist, but it seems perfectly reasonable that something like this should work. If it is just a limitation and not something I’m doing wrong, are there any suggestions for a workaround? The class I’m trying to write would really clean up my code.

Jon

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users