huh, that overload looks pointless. I should be able to remove the 2nd version of that method

oops was that my change to make isNotNull work on non nullable subjects?

I actually like that

isNotNull

doesn’t didn’t work on non-nullable objects

why?

Hm, this is kinda tricky. If the function has

<T : Any?>

then it's impossible to define that it returns an assertion enclosing a definitely non-null subject

For me it's not a big deal. Just revert it

right

Maybe it's a compiler bug and it should use the nullable version?

additional argument against

Builder<T>.isNotNull()

- if you're doing any generics (weird in tests, but probably can happen in complex projects?) then stuff can get confusing

fun <T> test(subject: T) {
    expectThat(subject).isNotNull()  
}

fun main() {
    test<Int?>(null)
}

afaik this will pass currently I guess it won't happen that often in strikt, as you would rather write a custom assertion, and then this won't happen as much I think, but if you need to do something like communicate interactively a with some generic payload, stuff can get iffy... (eg, do asserts in middle of communication of the payload and so, over different message types, maybe even collection types...)

nasty

oh wow i had a bad feeling. if we want to add that feature we need to test for this case

Yeah, I was fiddling with it a little yesterday and I think it may be due to the type signature of the function. Its generic is

<T : Any?>

and the receiver is

Assertion.Builder<T?>

which means the type could be say

String?

and then the receiver is

Assertion.Builder<String??>

well it's more like because it's a static call from the JVM view

I agree that both impls should check if the subject really is not null just to be sure

I pushed out a release that removes the overload for now. If there's a way to avoid the ambiguity I'm happy to re-add it, but it actually impacted someone here at work!

its probably not worth the hassle

I'd like to be able to define a single function, but it's very useful that

isNotNull

narrows the subject type from

T?

to

T

and I don't see a way to do that while allowing for a non-null subject going in

maybe with contracts?

hmm, I wonder yes

can't work with contracts, because:

expectThat(x) {
    isNotNull().somethingOnlyOnNonNullable()
    somethingOnlyOnNonNullable()
}

if first works because contracts, then the second has to work too (which it obviously can't)