I've read the requirements [0] section of the article and it doesn't contain anything that would prevent you from just storing all the flags in the decoder and using an id.

In fact, the article says

> With this (rather primitive) format I managed to encode 128 flags with varying success.

Which means that, actually, 7 bits would be enough.

So, this comment is (correctly) pointing out that requirements are imprecise.

You may find such "rules lawyering" obnoxious, but I think that in the real world tasks it is often useful to clarify such things, because it let's you avoid doing hard and complex work that is actually not needed.

I think that every experienced developer has this automatic response to reading a list of requirements: "here is a shortcut that will technically fulfill all the requirements. Please, either tell me that it is okay to do it, or update your requirements to close this loophole".

[0] https://read.vantezzen.io/miniflags#3d8e32040c2a808e8d95c8a0...

Yeah. I had to read the comment a few times to make sure that I'm not missing anything, but you are right. Those are two distinct things.

As a side note, the title is not accurate either because the method in the article can compress only one flag to 11 bits:

> Using this format, the average flag can be represented in 76 bits, with a median of 55 bits.

One can use Huffman encoding (the same encoding the article uses) to compress one of the flags to a single bit.

The actual article borders on just using IDs too. Things like the Union Jack are just stored as is.

The techniques here let you encode the currently existing flags but aren’t really enough to build a flag from scratch.