Fix Streaming and StreamingT dropWhile functions

[mikejcurry]

Default Int => Boolean in scalacheck just returns a function which
always returns the same value (true or false). This means that
operations like dropWhile are not tested accurately, as whilst the bounds (all true and all false) are checked, intermediate results which return different values based on input are not tested.

This fix creates a temporary Arbitrary instance for Int => Boolean and fixes the dropWhile on Streaming and StreamingT which were broken, and didn’t show up due to the deficiency in the Arbitrary[Int => Boolean] instance provided by scalacheck.

Maybe there is a better way to do these instances? This kind of hardcodes that the Int => Boolean returned is always just a comparison between the Int values, but seems better than always true/false.

[codecov-io]

Current coverage is 89.28%

Merging #856 into master will increase coverage by +0.01% as of d2ba4ae

@@            master    #856   diff @@
======================================
  Files          168     168       
  Stmts         2322    2323     +1
  Branches        75      75       
  Methods          0       0       
======================================
+ Hit           2073    2074     +1
  Partial          0       0       
  Missed         249     249       

Review entire Coverage Diff as of d2ba4ae

Powered by Codecov. Updated on successful CI builds.

[ceedubs]

Now that we have sbt-doctest in place, we should change these to be compiler-verified!

[ceedubs]

I submitted mikejcurry#1 to your PR branch

[ceedubs]

Yikes good catch. Thanks @mikejcurry!

[ceedubs]

This probably warrants a 4.0.1 release :| cc @non @travisbrown

[adelbertc]

I hope you mean 0.4.1 :-)

[ceedubs]

@adelbertc oops quite right :)

[ceedubs]

I think we can save an allocation by doing something like this here:
case s @ Cons(a, lt) => if (f(a)) Wait(lt.map(_.dropWhile(f))) else s

[mikejcurry]

Good spot - Thanks! - In general, is there any reason to do s @ and evaluate the expression to s instead of just evaluating to this? Aesthetically I prefer using this, but that is just personal preference - was wondering if there is any real reason I not aware of to prefer one of the other. Eitherways, I'll push through with the s @ ; because the only reason I have any preference for using this is aesthetic, and that likely comes from Java/C++

[non]

To answer your question: there are times when you get a finer-grained type from s @ ... (due to the pattern match ...) and then you would need to use s instead of this because you have better type information. If you don't need the extra type information then using this would be just fine; at that point it's just a stylistic preference.

[mikejcurry]

Cool - that makes a lot of sense - and thanks a million for following up!!!

I guess in this instance there would have been no value, as there is no additional type information required, but I can definitely imagine scenarios, where this could be valuable.

[ceedubs]

Yep, totally agree with what @non said. It didn't occur to me that this would work fine in this example. I have no strong preference.

[mikejcurry]

Thanks! - I actually don't have much preference - it's more natural defaults :-). I went with your suggestion anyway.

[non]

👍