On 5 Aug 2015 at 11:27, Gavin Lambert wrote:
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).
I'm more thinking that there is no point in adding features which have no proven use case yet. I don't mind adding a boolean flag which costs me nothing and cannot be buggy. I get much more worried about adding features which I cannot test and have no proven user base. Better I think to wait until a proven use case arises. BTW you may not be aware, but AFIO includes every historical release of itself within itself via submodule branch pins. In other words, if you build an application targeting v1 ABI of AFIO, that will work in perpetuity (or at least until I stop supporting it). AFIO already ships two versions of itself, v1 and v2. Hence I don't have the problems other Boost libraries have with changing API semantics down the line. I can do so without breaking anyone's code because there is a literal copy of previous AFIO's shipped every release.
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. :)
If you can persuade Beman I'll follow it. AFIO is intended as a set of extensions to Filesystem, not as a replacement and as such is wholly dependent on Filesystem. In other words, whatever Filesystem does I'll match. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/