# Requirement Machine Failure? **URL:** \ **Category:** Compiler\ **Tags:** compiler\ **Created:** [April 6, 2023, 10:57pm UTC](https://forums.swift.org/t/requirement-machine-failure/64235 "2023-04-06T22:57:21Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![SDGGiesbrecht](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sdggiesbrecht/32/4768_2.png) [@SDGGiesbrecht](https://forums.swift.org/u/SDGGiesbrecht)\ **Post date:** [April 6, 2023, 10:57pm UTC](https://forums.swift.org/t/requirement-machine-failure/64235/1 "2023-04-06T22:57:21Z")
@Slava_Pestov, you did much of the work on the [Requirement Machine](https://forums.swift.org/t/the-requirement-machine-a-new-generics-implementation-based-on-term-rewriting/55601), correct? Are you (or anyone with comparable expertise) able to decipher what is going on [here](https://github.com/SDGGiesbrecht/SDGCornerstone/actions/runs/4625329245)? Swift 5.8 is unable to compile source that [works with Swift 5.7](https://github.com/SDGGiesbrecht/SDGCornerstone/actions/runs/4625329249). The output from the compiler resembles the notation you used in your post, so it seems to have something to do with the generic signature minimization you wrote about. But I cannot tell if the compiler is finding a real problem with the source, or just confusing itself. Either way, it does not say what it was working on when it ran into trouble, so I do not know which part of the source triggered the confusion. Was it the protocol declaration itself, one of the related protocol conformances, the declaration of a generic function that uses the protocol, or a call made to such a generic function? Are you able to give any advice on how to evade the problem, preferably in a way that is source‐compatible for any clients and that does not break compatibility with Swift 5.7? ---
**Author:** ![Slava\_Pestov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slava_pestov/32/30204_2.png) [@Slava\_Pestov](https://forums.swift.org/u/Slava_Pestov)\ **Post date:** [April 6, 2023, 11:20pm UTC](https://forums.swift.org/t/requirement-machine-failure/64235/2 "2023-04-06T23:20:26Z")
> [@SDGGiesbrecht](#): > > Are you (or anyone with comparable expertise) able to decipher what is going on [here](https://github.com/SDGGiesbrecht/SDGCornerstone/actions/runs/4625329245)? Swift 5.8 is unable to compile source that [works with Swift 5.7](https://github.com/SDGGiesbrecht/SDGCornerstone/actions/runs/4625329249). Yes, thank you for the bug report, I will take a look. ```swift Splitting concrete equivalence classes did not reach fixed point after 2 attempts. Last attempt produced these requirements: conforms_to: τ_0_0 BidirectionalPattern same_type: τ_0_0.[Pattern]Match.[PatternMatch]Searched Data same_type: τ_0_0.[Pattern]Match.[PatternMatch]Searched.[BidirectionalPattern]Reversed.[Collection]SubSequence τ_0_0.[Pattern]Match.[PatternMatch]Searched.[BidirectionalPattern]Reversed.[Pattern]SubSequencePattern ``` ---
**Author:** ![SDGGiesbrecht](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sdggiesbrecht/32/4768_2.png) [@SDGGiesbrecht](https://forums.swift.org/u/SDGGiesbrecht)\ **Post date:** [April 6, 2023, 11:36pm UTC](https://forums.swift.org/t/requirement-machine-failure/64235/3 "2023-04-06T23:36:48Z")
By experimentation, I have figured out that the module can be made to build by removing the conformances to `SearchableBidirectionalCollection` and its inherited `BidirectionalPattern` from `Data` and several of `String`’s view types (which defeats the purpose). What these types appear to have in common is that `SubSequence == Self` and/or that `Element` is concrete. The other types that appear to successfully conform either have a distinct `SubSequence` or have conditional conformance based on a generic `Element` (e.g. `Array where Element: Equatable`). ---
**Author:** ![Slava\_Pestov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slava_pestov/32/30204_2.png) [@Slava\_Pestov](https://forums.swift.org/u/Slava_Pestov)\ **Post date:** [April 7, 2023, 12:22am UTC](https://forums.swift.org/t/requirement-machine-failure/64235/4 "2023-04-07T00:22:33Z")
I reduced a self-contained test case from your project and filed [Incorrect generic signature minimization causes failure in concrete equivalence class splitting · Issue #64995 · apple/swift · GitHub](https://github.com/apple/swift/issues/64995). Basically one weakness of the requirement machine (which was shared by the previous GenericSignatureBuilder) is that the handling of concrete types isn't too great. In your case, the root cause is the same-type requirement on the `Reversed` associated type in `BidirectionalPattern`: ```swift associatedtype Reversed: Pattern where Reversed.Searchable == ReversedCollection ``` If you could find a way to express your protocol without this exact requirement it would fix the problem. Keep an eye on that GitHub issue for further updates. ---
**Author:** ![SDGGiesbrecht](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sdggiesbrecht/32/4768_2.png) [@SDGGiesbrecht](https://forums.swift.org/u/SDGGiesbrecht)\ **Post date:** [April 7, 2023, 2:17am UTC](https://forums.swift.org/t/requirement-machine-failure/64235/5 "2023-04-07T02:17:19Z")
Thanks.