Tobias Roeser

> Started working on adding the message to the official BSP protocol: [build-server-protocol/build-server-protocol#673](https://github.com/build-server-protocol/build-server-protocol/pull/673) @lolgab Thank you! ❤️

Sorry @lolgab for me being naive and thinking the BSP project is the way to go. (Meanwhile, I think it's a corporate project serving the interest of some vendor. Decisions...

TBH, I lack a clear opinion on this change. I tend to hesitate, though. What I don't like is that it blurs the purpose of the API. Before, `Result.Failure` was...

I'm aware of `Exception` being added earlier into `Result.Failing`, and @lolgab is just trying to improve what we have. @lihaoyi Why we added `Exception` to `Failure` again? It would be...

@lolgab I think you made a good case for the motivation of `Result.Failure` being an `Exception`. Whereas I tried to point out the implications. Once, you are not directly in...

I guess I need to point something out. I'm not against having an return/fail-mechanism based on exceptions! I'm against reusing the existing `Result.Failure` type for it. `Result` is a `sealed...

I could also imagine some try-catch-block in the implicit conversion from `T` to `Result[T]`, such that each task implicitly converts inner caught `ResultFailureException`s to a `Result` type and we can...

`Result.Exception` needs to stay until we start to work on `0.13`. But I too think, its API is not that useful but hard to use. Instead, we could add an...

Is there some preceding discussion about this change, somewhere?

While I see the value of extra parameters for run and test, I don't see their use for compile, since compile is a prerequisite of the other and should be...