Skip to content

Commit d522d80

Browse files
committed
fix two typos
1 parent 534c853 commit d522d80

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

_sips/minutes/2019-12-18-sip-minutes.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -181,11 +181,11 @@ not, in fact, nullable, in practice, in the API. So there is a tricky balance:
181181
type to String | Null and deal with it with ifs and pattern matching or some flatMap-y API/syntax, every time,
182182
evne when you know it's not nullable? Or you can just say if it comes from Java then you just accept it might
183183
be a null, but then you don't have any checks any more in practice. So here the proposal - and it's one of the
184-
more delecate points - says that things that come from Java are a bit special. A String that comes from Java is
184+
more delicate points - says that things that come from Java are a bit special. A String that comes from Java is
185185
neither String nor String | Null, it's String | UncheckedNull. That type has some special properties, like you
186186
can dot-select on it, for example. It's something in the middle.
187187

188-
Guillaume asks: how in thie middle? What can you _not_ do?
188+
Guillaume asks: how in the middle? What can you _not_ do?
189189

190190
Seb: when it becomes something that is just String it will eagerly fail there. So if your Scala API declares
191191
something is a String, and you use a Java API that returns String | UncheckedNull, it will throw in the body of

0 commit comments

Comments
 (0)