Observable error

[headinthebox]

def error[T](exception: Throwable): Observable[T] = {
    toScalaObservable[T](rx.Observable.error(exception))
  }

This can return Observbale[Nothing] like empty and never or not?

[samuelgruetter]

Yes it can, because if no type parameter for T is given, the compiler infers the most precise type possible, which is Nothing:

val o1 = Observable.error(new Exception())      // creates an Observable[Nothing]

[samuelgruetter]

Oops, looks like I misunderstood the question, and then you misunderstood my answer.

I understood the question as "Can we use Observable.error as if it was defined without a type parameter and returning Observable[Nothing]"? And the answer to this question is yes.

But I would keep the additional type parameter in the current signature, because it has the advantage that we can give the desired type parameter explicitly if we wish to do so, which often improves type inference, as @zsxwing's example in #83 shows.

[zsxwing]

I think empty, never and error have the same problem: should we use Observable[Nothing]?

I tend to yes and prefer to make these methods consistent because:

• It's much like Nil. Nil also has similar problem. E.g.,

val o: List[Int] = Nil.map(v => v)
val x = 1
println(x + (Nil.head: Int))
val y: Int = Nil.head

• My examples in Optimize the 'error' signature #83 are contrived. I don't think people will write such codes. When they use empty, never or error, they usually have some other Observable with a known type parameter in hand and combining these Observables will work well with type inference.

[samuelgruetter]

I agree that we should make empty, never and error consistant. But I'd prefer adding type params to all of them because:

1. Scala's List.empty does so as well:

def empty[A]: List[A] 

2. There's no program which stops working if we add type parameters, but some stop working if we remove them.

3. This is a chance to help users when Scala's type inference is not smart enough.

[zsxwing]

Great points. I'm convinced.

[headinthebox]

Disagree. I absolutely hate to see any types. It is super irritating to be forced to specify the type in error. We should leverage covariance.

As long as we are not at 1.0 we should break people as we iterate towards a stable API.

I'll veto the change to add type parameters.

[zsxwing]

@headinthebox

Scala used List[Nothing] before. But @odersky changed it to List[A] in

scala/scala@14a631a#diff-65c966843f6b3b817df43968f326d160L580

override val empty: List[Nothing] = Nil => override def empty[A]: List[A] = Nil

[headinthebox]

i'll check with Martin.

[zsxwing]

@headinthebox any update?

[zsxwing]

ping @headinthebox

[zsxwing]

@headinthebox this is still pending...