A hypothetical OS that allows directories to be opened with an ifstream may reasonably answer true to both is_stream(p) and is_directory(p). Or maybe not. :-)
I think not. Dividing the world into non-overlapping categories is much easier:-)
It's only easier until an example comes up that doesn't fit the scheme, so you are forced to invent meta-categories (also known as "hacks" in some category theory circles) such as "other". :-)
"Capability bits" are cleaner. Is it openable with ifstream? file_bit. Is it iteratable with directory_iterator? directory_bit. Does it exist? !not_found_bit.
I'm only partially convinced. How useful is knowing that you can ifstream a directory? The only cases I can think of are so system specific that I have trouble seeing them in the context of Boost.Filesystem.
ReiserFS version 4 supports opening a directory as a file. eg: opendir("/foo") & open("/foo") both succeed. This is so that you can treat a directory as a file, so that you can treat directory entries as 'streams' within the file (cf. win32 named file-streams). Samba 4 is intending on using this facility to map win32 stream-open's to real POSIX file semantics.
When a socket is thrown your way, you just run it by the list and conclude that no bit needs to be set.
But that is about the same as having an other_flag, except that the name is 0 instead of other_flag. Giving it a name makes it more obvious that a return from status() may not have any of the other bits set
However it is implemented, it should be 'named' so that it is obvious to a person reading over the code, that the test is checking for a specific capability. Mathew