SwiftBaseLibrary: ISequence.contains ultimate infinite recursion bug

Version: 8.3.94.2007
Description:

After you guys migrated to Swift 3.0 syntax, and you added _ into contains declaration - so it will now ultimately call itself forever that will lead to StackOverflowException.

In Sequence_Extensions.swift:

@warn_unused_result public func contains(_ item: T) -> Bool {
	#if COOPER
	return self.contains(item)
	#elseif ECHOES
	return self.Contains(item)
	#elseif NOUGAT
	return self.contains(item)
	#endif
}

(Actually there is no contains method available on ISequence directly, so for Cooper self.contains won’t be found if you change the method definition)

Instead we can use the following implementation:

@warn_unused_result public func contains(_ item: T) -> Bool {
	return (self.indexOf { $0 == item } != nil)
}

@mh: Which also tells me that you should consider adding extensive Unit Tests to SwiftBaseLibrary.

Contributions welcome. :wink:

1 Like

With pleasure, after August though, on a very intense schedule now, also I will release our core utility library that works both with Apple’s Swift and Silver.

1 Like

Curiously, it should have SO’ed before, too. All the _ does is clarify it for Swift 3.0. Weird. I’ll need to review how vest to solve this — probably only keep the .NMET version, since/if Cocoa ands Java already have a proper lowercase contains() that matches, the extension is not really needed there?

At least when building for Cooper .contains() won’t be found on ISequence directly.

Just be careful since if there is some internal Elements API, whose declarations are not properly exposed in Swift 3.0, by some good chance the target can compile and the method calls might result in different overload being called, which might be difficult to spot.

Can you elaborate on that?

What I mean, is there is some internal Elements or any other class that in Swift 2 specified a declaration like:
func someFunction(item: SomeItem) and by some chance it will exposed to Swift 3 with the very same signature (without _), then some client code which used to call someFunc(thisItem) in Swift 2 might not produce the compile time error, if by chance there is new method declaration available as func someFunction(_ item: SomeItem), so that the method call will result in wrong overload being called.