Josh Bleecher Snyder

> Re ExitOnCompletion, do you have any examples? Or other name alternatives to choose from? :) Example: the Go compiler. Refactoring it to be re-usable is a gigantic task, but...

> I am not sure it's Fuzz function responsibility to know about layout of files on disk. I agree, although I do think there should be a reasonable default, and...

> A first idea is providing a FromT function that creates a stub F from testing.T to use in unit-tests. Interesting, but not germane (I think) to the new fuzz...

> libfuzzer flags Interesting. None strike me as obvious must-haves for v0. Let's do this incrementally.

Based on all the conversation above, I feel reasonably confident in taking a basic step: minimal fuzz.F, accept a single byte slice in the signature. I will work on that...

> It also means that there are restrictions on the Fuzz function signature (no interfaces, I'm guessing) Another restriction: no unexported types. (Can't create those types from a generated `main`...

> FWIW, the use cases that I have in mind can also be handled without integer priority, but by calling Interesting multiple times SGTM.

Now that I'm eyeball deep in this, I remember why I thought `fuzz.F` needed to be an interface: There's nowhere good to put the concrete implementation. If we put it...

The more I think about this, the less convinced I am that we should go out of our way to implement `testing.TB`. There's a ton of duplication, because testing and...

Maybe I’m missing something. I’m saying I don’t see the point in embedding or implementing testing.TB. The overlap with what fuzzing actually needs is too small. We may as well...