[RSS] Going beyond the empty set: Embracing the power of other empty things

https://devblogs.microsoft.com/oldnewthing/20240923-00/?p=110297

@buherator

The inability to handle zero-byte buffers makes everybody’s life harder.
Zero. It’s a valid number. Please support it.

It's wild that zero isn't supported when everything is in 1s and 0s.

@buherator

From the perspective of integrating and using such code, I think there are three possibilities that one usually needs to handle to cover the “oops, couldn’t produce the thing you wanted, sorry consumer” cases the author discusses, regardless:

1. Check for null (the author dislikes producing null, but that doesnt mean layers under their code might not produce nulls that the author’s code unintentionally propagates up to consumers)

2. Check for empty (the author prefers this)

3. Check for typed exceptions (I guess the author doesn’t cover this and I am surprised they don’t discuss?)

I appreciate the author’s take on why empty set outputs might be nicer, and that also fails to change the fact that they are just one cat and all the other library authoring cats out there will have divergent strong opinions that their implementations follow 🥲

@kaoudis I think what you describe is a slightly different case from the one in the post: you want to explicitly detect failure, while the author doesn't (note that there are no checks for empty).

Considering that even the Big Fat Policy Cat mentioned in the post couldn't prevent digression from the stated rule, it's a good question if trusting an API in a system with nullable types is a good idea in the first place...

Anyway, Mr.Chen usually answers comments, so it may worth to bring up these points at the source too!

@buherator :D I may just~ thanks for the idea