Kotlin result

[jcrist1]

Uses kotlin result. An attempt to address #697. I have to admit I'm not a big fan. On the plus side it is more ergonomic, but a big minus is we completely erase the type of the error. Unfortunately as per the discussion in the issue we can't make a generic wrapping class. Instead we would have to change the error type to extend Throwable. Let me know what y'all think of this.

[Manishearth]

(a) can we get rid of Res?
(b) Can we replace the .ok/.err methods that seem to be globally added (?) with local free functions?

[jcrist1]

(a) can we get rid of Res?

Yes and done.

(b) Can we replace the .ok/.err methods that seem to be globally added (?) with local free functions?

I'm not sure I understand. We can move them to always be local to the class, but I don't understand the benefit as it would just duplicate the code accross classes. Could you elaborate on the reasoning? In any case it should be a small change. I've made them internal now, so they shouldn't escape the library.

As for free functions, I'm not familiary with the term. A quick googling tells me it's like a function which doesn't take a "self" param in Rust's terminology. However, a lot of the code flow assumes that the .ok() and .err() will be applied as postfix operations, as such it would require more changes to get them to be free functions, if I'm understanding it correctly.

[Manishearth]

We can move them to always be local to the class,

No I just meant package local. internal is fine.

As for free functions, I'm not familiary with the term. A quick googling tells me it's like a function which doesn't take a "self" param in Rust's terminology.

I was thinking of a free function as in the equivalent of a standalone fn in rust, not on an object. If Kotlin doesn't have that, then perhaps a static method on some shared utility class.

But this is fine too!!

[Manishearth]

cc @emarteca

[emarteca]

Thanks for doing this!

I just made a PR making the struct and opaque error results Throwable; I think it's worth being able to inspect/use the error on the Kotlin side. #741

Other types are hard to return so that Kotlin can actually use them, since we can't make them Throwable too.
Do we think it might be worth creating an error wrapper type for each primitive? Unfortunately, as you guys noted, it seems the JVM languages won't let us make a generic class Throwable, b/c it's unable to reflect on the type. :(