Ambiguous use of distinctUntilChanged

[reactivecocoa]

Ambiguous use of distinctUntilChanged

[mdiep]

Your best option is probably to use https://github.com/ReactiveCocoa/ReactiveObjCBridge/ with https://github.com/ReactiveCocoa/ReactiveSwift/

[vitorhugomagalhaes]

@mdiep Thanks for the comment.

I'm currently migrating to Swift 3 and that's the main reason for this errors. Still, it must be done.

The problem of using ReactiveObjcBridge + ReactiveSwift is the boilerplate of bridging we will have in the code. A lot of our swift code is exposed to Objective-C and that already sucks.

It could make sense to migrate everything to swift in the near future.

Meanwhile, I found that adding the explicit type seems to work. I still don't understand why it can infer the correct type since the RACObserve function returns a RACSignal type.

Regarding RACStream it does not implement lightweight generics. Is there a reason for it ?

BR,

[andersio]

/cc @erichoracek

[vitorhugomagalhaes]

I have divided the several signals to understand where the ambiguity occurs:

            let x1: RACSignal = self.RACObserve(self.settingsService.mib, "user_settings.pois.main_map_visible_categories")
            let x2: RACSignal<AnyObject>! = x1.ignore(nil)
            let x3 = x2.distinctUntilChanged()

Even by explicitly indicating the RACSignal type the compiler still founds it ambiguous.

[erichoracek]

This appears to be due to a Swift compiler issue that results from a method being declared both on a non-generic base class (RACStream), as well as on a generic subclass (RACSignal<ValueType>). Either of the following appear to resolve it:

1. Declaring RACStream operations (e.g. distinctUntilChanged) as NS_SWIFT_UNAVAILABLE.
2. Giving RACStream a lightweight generic ValueType annotation.

The second option appears to be the most preferable, since that leaves -[RACStream distinctUntilChanged] available to Swift consumers. Since the NS*/NSMutable* Foundation collections classes appear to work in ObjC and Swift with this pattern, I don't foresee there being an issue with attempting the second approach to fix this issue in RACObjC.

As such, unless anyone knows of any issues, I'll go ahead and make a PR with the second option.

[erichoracek]

@vitorhugomagalhaes please try 2.1.2 and make sure it resolves your issue. Let me know if it doesn't—thanks!

[vitorhugomagalhaes]

@erichoracek Thanks.

I will test the new version and get back to you asap.

[erichoracek]

I've filed this issue as https://bugs.swift.org/browse/SR-3529