Joshua Gleitze

The proposed solution would, of course, look a little awkward when specifying the type of the exception that must not occur: ``` expect { checkNotNull(value) }.notToThrowAndResult().toBe("foo") ``` We could force...

Here’s where I encountered the issue: https://github.com/jGleitz/testfiles/blob/master/base/src/test/kotlin/DefaultTestFilesSpec.kt#L144 It previously read ```kotlin expect { testFiles.createFile("test") }.notToThrow { // check that / \ is not messing up the directory structure parent.fileName.matches(Regex(".test with...

Hm, I get your points. I gave it some more thought and now I also dislike `notToThrowAnd` (even though I considered it myself). My reason is that: 1. There would...

> Feature extractors always provide both versions. I guess this sentence is a good explanation for why I am irritated with the current solution: `notToThrow` should, to my mind, not...

> So... if `notToThrow` is not a feature extractor then you would still deal with `Expect R>` after the call. Not quite. I don’t think that it’s imperative that every...

Okay, so let me dissect the whole situation a little more. The beginning will be all old news for you, but helps me. In the end I’ll make another bold...

`p` does not work, as reported in the initial report. I didn’t know about `f0`. Using `f0` works. Still, I think it might make sense to remove `f(KProperty0)`. Because then,...

As a quick test, the following compiles with Kotlin 1.4: ```kotlin class Foo { val bar: String = "baz" } fun Expect.myFeature(functionOrPropertyCreator: T.() ->KCallable): Expect = TODO() expect(Paths.get("foo/bar")).myFeature { ::isAbsolute...

> note that f works for java getters. It does not work where java getters are overloaded where one overload has 0 parameters. That is not the problem here. There...

> or do you want to create a PR yourself? I’d like to do the PR, but let’s create a ticket. I am quite busy and can’t make promises when...