Scala Buggabot

@retronym said (edited on Nov 6, 2014 1:15:16 PM UTC): I don't think we can break the invariant that: ```scala def prop(t: Throwable): Boolean = try { Try(throw t).get }...

@jrudolph said: Why? Would you also suggest this invariant: ```scala def prop(t: Throwable): Boolean = try { Try(throw t) match { case Success(t) => t } } catch t1: Throwable...

@jrudolph said: A precedent: `java.util.concurrent.Future.get` wraps an exception that occurred during running a Future into an `ExecutionException`. http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html#get()

@retronym said: As I understand it, `Try` is meant to be a library equivalent of the built in `try`. It is a way to transport an exception across a thread...

@jrudolph said: First, I agree that using `setStackTrace` could be a solution (though a non-standard one AFAIK). Also, yes, checked exceptions are probably the main reasons for the wrapper exceptions....

Imported From: https://issues.scala-lang.org/browse/SI-9292?orig=1 Reporter: Espen Wiborg (espenhw) Affected Versions: 2.11.6

Imported From: https://issues.scala-lang.org/browse/SI-8901?orig=1 Reporter: @rkuhn See #7886

@retronym said: I believe the unsound inference of T=Any is a duplicate of bug #7886. Supporting pattern matching type variables in constructor patterns is an interesting idea.

@paulp said: I +/- implemented this (via a macro!) [here](https://github.com/paulp/psply/blob/master/src/main/scala/PatternMacros.scala). It's tricky because the parser generates the wrong tree if you provide type arguments in a constructor pattern - you...

@milessabin said: @paulp can I persuade you to translate that to a PR against the compiler? As the tests for your macro demonstrate, this gets along very nicely with literal...