Although the SCAN docs specifically state that the COUNT limit is applied before the MATCH pattern and thus the number of results may be less than count, this results in extra database calls when a specific number of SCAN results is needed. Being able to specify an exact number of elements returned from SCAN would be preferable.
What are the drawbacks to a SCAN implementation that continues until the number of matched items in the cursor is equal to the count parameter? Does is present performance problems like the KEYS command?
@datasaur basically what you propose is antithetical to SCAN itself that was designed to don't block, so I just use a pattern that is not present in the key space, and the result is an unique unblocked full-scan of the key space. The current design allows you to select the tradeoff by using a bigger count if you have too little results, and at the same time it clearly exposes to the user the tradeoff: if you don't see results after multiple calls, you are looking for a needle inside an haystack, so probably a different design is needed (like indexing stuff into a sorted set). That's why this design was not considered.