Merge branch 'master' of https://github.com/ReactiveX/RxSwift

# By Krunoslav Zaher (23) and others
# Via Krunoslav Zaher
* 'master' of https://github.com/ReactiveX/RxSwift: (72 commits)
  Improves unit tests.
  Updates RxDataSources.
  Changes 2.5 to 2.5.0.
  Adds 2.5.0 changes to CHANGELOG.
  Makes `NSTextField` implement `RxTextInput`.
  Fixes Wikipedia automation tests.
  Improves delegate proxy messaging. ReactiveX#675
  Turns off bitcode for RxTests. ReactiveX#584
  Release 2.5
  More comprensible `ActivityIndicator`
  Improve language in comment
  Use new Swift selector syntax in comment
  Update comment to use new non-deprecated method
  Fix argument key in comment
  Typo in comment 'extensions' with an 's'
  Improves documentation for `DelegateProxy.observe`. ReactiveX#654
  Adds unit test for only setting different text values.
  Provides explanations for check.
  Fixes problems with two way binding that was caused by `rx_text` and always setting the text value even when the value was equal, and thus clearing the marked text state. ReactiveX#649
  Add missing Next link
  ...

CHANGELOG.md

@@ -3,7 +3,29 @@ All notable changes to this project will be documented in this file.
 
 ---
 
-## [2.4](https://github.com/ReactiveX/RxSwift/releases/tag/2.4)
+## [2.5.0](https://github.com/ReactiveX/RxSwift/releases/tag/2.5.0)
+
+#### Features
+
+* Exposes `installForwardDelegate`.
+* Adds `proxyForObject` as protocol extension and deprecates global function version.
+* Improves `installForwardDelegate` assert messaging.
+* Improves gesture recognizer extensions to use typed gesture recognizers in `rx_event`.
+* Adds `RxTextInput` protocol to enable creating reactive extensions for `UITextInput/NSTextInput`.
+* Adds `rx_willDisplayCell` and `rx_didEndDisplayingCell` extensions to `UITableView`.
+* Improves playgrounds.
+
+
+#### Anomalies
+
+* Fixes in documentation.
+* Turns off Bitcode for `RxTests` CocoaPods integration.
+* Fixes `UITextField.rx_text` and `UITextView.rx_text` integrations to be more robust when used with two way binding.
+* Fixes two way binding example code so it now properly handles IME used in Asian cultures and adds explanations how to properly perform two way bindings. https://github.com/ReactiveX/RxSwift/issues/649
+* Removes `distinctUntilChanged` from control extensions. https://github.com/ReactiveX/RxSwift/issues/626
+
+
+## [2.4.0](https://github.com/ReactiveX/RxSwift/releases/tag/2.4)
 
 #### Features
 

Documentation/API.md

@@ -3,7 +3,7 @@ API
 
 ## RxSwift supported operators
 
-In some cases there are multiple aliases for the same operator, because on different platforms / implementations, the same operation is sometimes called differently. Sometimes this is because historical reasons, sometimes because of reserved language keywords.
+In some cases there are multiple aliases for the same operator, because on different platforms / implementations, the same operation is sometimes named differently. Sometimes this is because of historical reasons, while sometimes because of reserved language keywords.
 
 When lacking a strong community consensus, RxSwift will usually include multiple aliases.
 
@@ -26,6 +26,7 @@ Operators are stateless by default.
  * [`timer`](http://reactivex.io/documentation/operators/timer.html)
 
 #### Transforming Observables
+
   * [`buffer`](http://reactivex.io/documentation/operators/buffer.html)
   * [`flatMap`](http://reactivex.io/documentation/operators/flatmap.html)
   * [`flatMapFirst`](http://reactivex.io/documentation/operators/flatmap.html)
@@ -35,6 +36,7 @@ Operators are stateless by default.
   * [`window`](http://reactivex.io/documentation/operators/window.html)
 
 #### Filtering Observables
+
   * [`debounce` / `throttle`](http://reactivex.io/documentation/operators/debounce.html)
   * [`distinctUntilChanged`](http://reactivex.io/documentation/operators/distinct.html)
   * [`elementAt`](http://reactivex.io/documentation/operators/elementat.html)
@@ -71,6 +73,7 @@ Operators are stateless by default.
   * debug
 
 #### Conditional and Boolean Operators
+
   * [`amb`](http://reactivex.io/documentation/operators/amb.html)
   * [`skipWhile`](http://reactivex.io/documentation/operators/skipwhile.html)
   * [`skipUntil`](http://reactivex.io/documentation/operators/skipuntil.html)
@@ -406,6 +409,13 @@ extension UIActivityIndicatorView {
 }
 ```
 
+```swift
+extension UINavigationItem {
+
+    public var rx_title: AnyObserver<String?> {}
+}
+```
+
 **OSX**
 
 ```swift

Documentation/ComparisonWithOtherLibraries.md

@@ -2,18 +2,18 @@
 
 RxSwift is somewhat similar to ReactiveCocoa since ReactiveCocoa borrows a large number of concepts from Rx.
 
-One of the main goals of this project was to create a significantly simpler interface that is more aligned with other Rx implementations, offers richer concurrency model, offers more optimization opportunities and is more aligned with built-in Swift error handling mechanisms.
+One of the main goals of this project was to create a significantly simpler interface that is more aligned with other Rx implementations, offers a richer concurrency model, offers more optimization opportunities and is more aligned with built-in Swift error handling mechanisms.
 
-We've also decided to only rely on Swift/llvm compiler and not introduce any external dependencies.
+We've also decided to only rely on the Swift/llvm compiler and not introduce any external dependencies.
 
-Probably the main difference between these projects is the difference of approach in building abstractions.
+Probably the main difference between these projects is in their approach in building abstractions.
 
 The main goal of RxSwift project is to provide environment agnostic compositional computation glue abstracted in the form of observable sequences.
-We then aim to improve the experience of using RxSwift on specific platforms. To do this RxCocoa  uses those generic computations to build more practical abstractions and wrap Foundation/Cocoa/UKit frameworks. That means that other libraries give context and semantics to the generic computation engine RxSwift provides such as `Driver`, `ControlProperty`, `ControlEvent`s and more.
+We then aim to improve the experience of using RxSwift on specific platforms. To do this, RxCocoa uses generic computations to build more practical abstractions and wrap Foundation/Cocoa/UKit frameworks. That means that other libraries give context and semantics to the generic computation engine RxSwift provides such as `Driver`, `ControlProperty`, `ControlEvent`s and more.
 
-One of the benefits to representing all these abstractions as a single concept; ​_observable sequences_​, is that all computation abstractions built on top of them are also composable in the same fundamental way. They all follow the same contract and implement the same interface.
+One of the benefits to representing all of these abstractions as a single concept - ​_observable sequences_​ - is that all computation abstractions built on top of them are also composable in the same fundamental way. They all follow the same contract and implement the same interface.
  It is also easy to create flexible subscription (resource) sharing strategies or use one of the built-in ones: `share`, `shareReplay`, `publish`, `multicast`, `shareReplayLatestWhileConnected`...
 
-This library also offers fine-tunable concurrency model. In case concurrent schedulers are used, observable sequence operators will preserve sequence properties. The same observable sequence operators will also know how to detect and optimally use known serial schedulers. ReactiveCocoa has a more limited concurrency model and only allows serial schedulers.
+This library also offers a fine-tunable concurrency model. If concurrent schedulers are used, observable sequence operators will preserve sequence properties. The same observable sequence operators will also know how to detect and optimally use known serial schedulers. ReactiveCocoa has a more limited concurrency model and only allows serial schedulers.
 
-Multithreaded programming is really hard and detecting non trivial loops is even harder. That's why all operators are built in a fault tolerant way. Even in case element generation occurs during element processing (recursion), operators will try to handle that situation and prevent deadlocks. That means that in worst possible case programming error will cause stack overflow, but users won't have to manually kill the app, and you will get crash report in error reporting systems so you can find and fix the problem.
+Multithreaded programming is really hard and detecting non trivial loops is even harder. That's why all operators are built in a fault tolerant way. Even if element generation occurs during element processing (recursion), operators will try to handle that situation and prevent deadlocks. This means that in the worst possible case programming error will cause stack overflow, but users won't have to manually kill the app, and you will get a crash report in error reporting systems so you can find and fix the problem.

Documentation/DesignRationale.md

@@ -11,49 +11,49 @@ enum Event<Element>  {
 }
 ```
 
-Let's discuss pros and cons of `ErrorType` being generic.
+Let's discuss the pros and cons of `ErrorType` being generic.
 
-If you have generic error type you create additional impedance mismatch between two observables.
+If you have a generic error type, you create additional impedance mismatch between two observables.
 
 Let's say you have:
 
 `Observable<String, E1>` and `Observable<String, E2>`
 
-There isn't much you can do with them without figuring out what will be the resulting error type.
+There isn't much you can do with them without figuring out what the resulting error type will be.
 
-Will it be `E1`, `E2` or some new `E3` maybe? So you need a new set of operators just to solve that impedance mismatch.
+Will it be `E1`, `E2` or some new `E3` maybe? So, you would need a new set of operators just to solve that impedance mismatch.
 
-This for sure hurts composition properties, and Rx really doesn't care about why sequence fails, it just usually forwards failure further down the observable chain.
+This hurts composition properties, and Rx isn't concerned with why a sequence fails, it just usually forwards failures further down the observable chain.
 
-There is additional problem that maybe in some cases operators will fail for some internal error, and in that case you won't be able to construct resulting error and report failure.
+There is an additional problem that, in some cases, operators might fail due to some internal error, in which case you wouldn't be able to construct a resulting error and report failure.
 
-But ok, let's ignore that and assume we can use that to model sequences that don't error out. It looks like it could be useful for that purpose?
+But OK, let's ignore that and assume we can use that to model sequences that don't error out. Could it be useful for that purpose?
 
-Well yes, it potentially could be, but lets consider why would you want to use sequences that don't error out.
+Well yes, it potentially could be, but let's consider why you would want to use sequences that don't error out.
 
-One obvious application would be for permanent streams in UI layer that drive entire UI. But when you consider that case, it's not really only sufficient to use compiler to prove that sequences don't error out, you also need to prove other properties. Like that elements are observed on `MainScheduler`.
+One obvious application would be for permanent streams in the UI layer that drive the entire UI. When you consider that case, it's not really sufficient to only use the compiler to prove that sequences don't error out, you also need to prove other properties. For instance, that elements are observed on `MainScheduler`.
 
-What you really need is a generic way to prove traits for sequences (`Observables`). And you could be interested in a lot of properties. For example:
+What you really need is a generic way to prove traits for observable sequences. There are a lot of properties you could be interested in. For example:
 
 * sequence terminates in finite time (server side)
 * sequence contains only one element (if you are running some computation)
 * sequence doesn't error out, never terminates and elements are delivered on main scheduler (UI)
 * sequence doesn't error out, never terminates and elements are delivered on main scheduler, and has refcounted sharing (UI)
 * sequence doesn't error out, never terminates and elements are delivered on specific background scheduler (audio engine)
 
-What you really want is a general compiler enforced system of traits for observable sequences, and a set of invariant operators for those wanted properties.
+What you really want is a general compiler-enforced system of traits for observable sequences, and a set of invariant operators for those wanted properties.
 
-A good analogy IMHO would be
+A good analogy would be:
 
 ```
 1, 3.14, e, 2.79, 1 + 1i      <->    Observable<E>
 1m/s, 1T, 5kg, 1.3 pounds     <->    Errorless observable, UI observable, Finite observable ...
 ```
 
-There are many ways how to do that in Swift by either using composition or inheritance of observables.
+There are many ways to do such a thing in Swift by either using composition or inheritance of observables.
 
-Additional benefit of using unit system is that you can prove that UI code is executing on same scheduler and thus use lockless operators for all transformations.
+An additional benefit of using a unit system is that you can prove that UI code is executing on the same scheduler and thus use lockless operators for all transformations.
 
-Since Rx already doesn't have locks for single sequence operations, and all of the remaining locks are in statefull components (aka UI), that would practically remove all of the remaining locks out of Rx code and create compiler enforced lockless Rx code.
+Since RxSwift already doesn't have locks for single sequence operations, and all of the locks that do exist are in stateful components (e.g. UI), there are practically no locks in RxSwift code, which allows for such details to be compiler enforced.
 
-So IMHO, there really is no benefit of using typed Errors that couldn't be achieved cleaner in other ways while preserving Rx compositional semantics. And other ways also have huge other benefits.
+There really is no benefit to using typed Errors that couldn't be achieved in other cleaner ways while preserving Rx compositional semantics.