You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So why was `>-` chosen in the end? Well, it was a difficult decision.
168
-
169
-
Why wasn't standard function application operator used?
169
+
### Why wasn't standard function application operator used?
170
170
171
171
I've first tried to find a similar operator in swift core libraries, but couldn't find it. That meant that I'll need to define something myself or find some third party library that contains reference function application operator definition and use it.
172
172
Otherwise all of the example code would be unreadable.
173
173
174
-
Why wasn't some standard library used for that operator?
174
+
### Why wasn't some standard library used for that operator?
175
175
176
176
Well, I'm not sure there is a clear consensus in the community about funtion application operators or libraries that define them.
177
177
178
-
Why wasn't function application operator defined only for `Observables` and `Disposables`?
178
+
### Why wasn't function application operator defined only for `Observables` and `Disposables`?
179
179
180
180
One of the solutions could have been to provide a specialized operator that just works for `Observables` and `Disposables`.
181
181
In that case, if an identically named general purpose function application operator is defined somewhere else, there would still be collision, priority or ambiguity problems.
182
182
183
-
Why wasn't some more standard operator like `|>` or `~>` used?
183
+
### Why wasn't some more standard operator like `|>` or `~>` used?
184
184
185
185
`|>` or `~>` are probably more commonly used operators in swift, so if there was another definition for them in Rx as general purpose function application operators, there is a high probability they would collide with definitions in other frameworks or project.
186
186
187
187
The simplest and safest solution IMHO was to create some new operator that made sense in this context and there is a low probability anyone else uses it.
188
188
In case the operator naming choice was wrong, name is rare and community eventually reaches consensus on the matter, it's more easier to find and replace it in user projects.
189
189
190
-
I have experimented for a week with different operators and in the end these are the reasons why `>-` was chosen
190
+
### Rationale why `>-` was chosen
191
191
192
192
* It's short, only two characters
193
193
* It looks like a sink to the right, which is a function it actually performs, so it's intuitive.
0 commit comments