On 5/08/2015 10:14, Niall Douglas wrote:
I guess that depends on usage cases -- if it's most common to write code like if (type() == symlink_file) { do something with target(); } then you have a point. Although code that has sufficient error checking should be able to cope with the idea of a symlink that has an unreadable target.
But it seems odd to me to claim that a file is *not* a symlink just because you're told that it's a type of symlink that you don't know how to read.
I'd like to think AFIO's symlinks are "POSIX(-y) symlinks".
That's least-common-denominator thinking. Which is hard to get away from when building a cross-platform abstraction layer, I know, but "because it's POSIX" isn't really a good justification either. There are some things that POSIX is very bad at (mostly for historic reasons). If you have a function that operates on symlinks, then it should operate on *all* symlinks, not merely a subset of them. Like I said though, it's possible the distinction is academic and not practical; I don't know if there are any other kinds of surrogates in the wild. So I can understand the reluctance. :)
Given the Filesystem TS has shipped, I'd say that moment has passed.
Too late to be in the standard (yet), maybe. But one of the roles of Boost is to be better than the standard, so it can be the *next* standard. :)