Enforced nullability on get()'s return type

Question

Enforced nullability on get()'s return type

lopes-felipe opened this issue 3 years ago · comments

I just migrated from 2.2.0 to the current latest version (5.1.0) and the main diference I saw was the nullable success, which I found just great!

But, one thing that I didn't get was the signature change on the get() method. Given that Result.Success<V>'s V can now be a nullable type, why does the Result's abstract get() has to have an "enforced" nullable return (: V?).

This feels somewhat counter intuitive to me, given that, even if I have a non-nullable Result value (e.g.Result<String, Exception>), its get() will always return a nullable one (String?), which just includes an (apparently) unnecessary complexity to handle the return.

Is there a particular reason for this design? Perhaps some use case that I'm not seeing right now? If no, I would like to propose a change removing this enforced nullability on get()'s return type: #91

Kittinun Vantasin · Answer 1 · Wed Jul 28 2021 17:35:18 GMT+0800 (China Standard Time)

First of all thanks for using Result! The reason behind this is probably that it was just an overlooking on my part. I tried to think what was the use case that I tried to enforce this, but apparently it looks like it has nothing ...

Felipe Lopes · Answer 2 · Thu Jul 29 2021 00:51:27 GMT+0800 (China Standard Time)

Awesome @kittinunf! Thanks for taking some time to look into this, this change's gonna be really useful from our side! :D

Do you have some sort of version publication schedule? No rush of curse, its just so I can organize myself for it.

Thank you again and best regards!

Kittinun Vantasin · Answer 3 · Fri Jul 30 2021 13:01:23 GMT+0800 (China Standard Time)

I found a couple of bugs and improvement that I wanna land into the next version. Would you mind wait a bit sir? I think I would love to add mapBoth into the Result as well. Since it seems to be overlooked it in my first kmm run.

Felipe Lopes · Answer 4 · Sat Jul 31 2021 01:13:42 GMT+0800 (China Standard Time)

Sure, absolutely no problem! In fact, we at Alice have been creating a few internal extension functions for Result as well, so if you want to, you could create a couple of issues and we would be glad to help you implement them as soon as possible! :D

Kittinun Vantasin · Answer 5 · Mon Aug 02 2021 11:36:44 GMT+0800 (China Standard Time)

@lopes-felipe more than welcome for that 👍

Kittinun Vantasin · Answer 6 · Wed Aug 25 2021 20:01:01 GMT+0800 (China Standard Time)

Just to make sure the new version should support this finally. Please report back if there is problem or anything.