In the current design, a check() must return a result object.
This is fine, but perhaps it could be interesting in some cases to be able to yield an indefinite amount of results. This is something that can be detected by the check runner code and responsibly handled.
In my opinion, it should be fair game for a bunch of result objects to be yielded, but if one of them is an error, then the final result of that check() is a FAILURE state.. but it would have still caught any warnings and successes yielded along the way, and not stopped at the first error.
I think this would open the door to more elegant code than having everyone reinvent their own "collect N errors and return one result" logic all over the place.
In the current design, a
check()mustreturna result object.This is fine, but perhaps it could be interesting in some cases to be able to
yieldan indefinite amount of results. This is something that can be detected by the check runner code and responsibly handled.In my opinion, it should be fair game for a bunch of result objects to be yielded, but if one of them is an error, then the final result of that check() is a FAILURE state.. but it would have still caught any warnings and successes yielded along the way, and not stopped at the first error.
I think this would open the door to more elegant code than having everyone reinvent their own "collect N errors and return one result" logic all over the place.