In many contexts,
nil is a special value meaning "no value" or similar. In many of those contexts,
nil would not be a meaningful normal value anyway (or both meanings coincide), so there are no difficulties.
The question arises of how best to represent a normal value of
nil in those contexts where
nil is already a special value, since we then need to distinguish between these two incompatible meanings of
There is of course the traditional strategy of using a second value indicating whether the first value is meaningful, as gethash does, but this is almost always overkill. Reserving
nil as the special value is the right call in most contexts, even when
nil might theoretically or occasionally make sense as a normal value.
Yet it might still happen that someone needs to represent a normal value of
nil in such contexts. Traditionally, users would choose an arbitrary stand-in value on an ad-hoc basis, and this might need to be documented, or might be left undocumented, leaving other users to choose their own arbitrary stand-in values anew. fakenil provides
nil*, a canonical value to use in such scenarios. Besides slight increases in code quality, convenience and ergonomics, using this specific stand-in value instead of arbitrary other stand-in values helps tracking the usage of this idiom, and other libraries can reference fakenil (which is fully and solely dedicated to this concept) instead of inventing and documenting their own similar concept or leaving the issue open.