https://kotlinlang.org
Join Slack
If I have: ```val foo: Either<Error, List<Bar>>? nullable { val baz: List<Bar>...
# arrow
d
If I have:
Copy code
val foo: Either<Error, List<Bar>>?

nullable {
   val baz: List<Bar> = foo.bind().bind() // this doesn't seem to be valid... how do I do this?

   val baz2: List<Bar> = ensureNotNull(foo).bind() // this also doesn't seem to be valid...
}
a
inside 
nullable
you can only 
raise
values of type 
null
(so you don’t “forget” information, although this design could be revisited)
you should be able to do
Copy code
foo.mapLeft { null }.bind()
sorry, my bad, I didn’t see the 
?
at the end
then it should be something like
Copy code
foo.bind().mapLeft { null }.bind()
d
Which isn't really as readable... maybe having 
bind()
with a different name for this, so that people will make the conscious choice to ignore the extra information...
The whole point I chose to use 
nullable { }
was to go with the happy path... and let everything else be null.
Maybe 
bind { null }
for `Either`s? Or ``bindOrMap { null }` ... would be better than using two different binds meaning two different things and that map in the middle...
a
(if it seems a good design I will add KDoc and those things)
d
From looking at the tests I don't really understand what the difference between bind() and bindAny() is...?
y
Good to note btw that you can do:
Copy code
nullable {
  withError({ _: Any? -> null}) {
    foo.bind().bind()
  }
}
Maybe this pattern should have a raise builder? Maybe something like 
nullableAny {}
that forgets all the error information.
Looking at the PR, I don't like the design of 
raiseAny
because it won't work well with context receivers. I think nullable should simply have 
Raise<Any?>
Inside of it, or we should introduce a new builder that does that, but having a new method won't work in a contexts world.
d
I think the idea was to be able to "choose" whether to ignore or not in the same block. With a new builder, you're choosing to ignore everything and might inadvertently ignore something important.
y
Hmmmmm, then maybe we could have both worlds? Or we could have a 
ignoreErrors { }
block that only works inside a 
Raise<Null>
and gives you a receiver of 
Raise<Any?>
, Although I can see how that's less user friendly
a
that’s interesting… I’ll try that one too 🙂
I like the connection brought by @Youssef Shoaib [MOD] with 
withError
, because 
ignoreErrors
is simply 
withError
with a bit better inference
d
Thanks for this PR! I guess out of this whole discussion that's really the best that can be done, and it'll certainly come in handy in certain cases!
a
merged! it will come out in 1.2.1 (which is now stuck because of problems with Kotlin 1.9)
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by