Beman wrote:
Well I'm afraid we don't know what that is. The (only)
good reason to
use base_name() is that there is precedent; it's not because it makes particularly "good sense." You yourself find it counterintuitive, IIUC.
That's correct. I'm only suggesting it because of the precedent.
If "base" _did_ make any sense, I would guess that base_path() was the identity function.
How about parent_directory(), containing_directory(), container_path(), container(), or parent()?
There is also a precedent for dirname. I think basename/dirname are both posix functions (but I'm stuck in windows so don't take my word). You could have : dir_name = branch_path base_name = leaf extension = extension Then base_name(f, extension(f)) = basename(f) <snip>
Comments?
I worry a bit about the chance of silent misbehavior due to basename/base_name spelling errors, and about what happens when both names make it into the same codebase.
I don't like that either, but (1) there doesn't seem much choice if "base*" is to be the new name, and (2) the problem doesn't last indefinitely since the deprecated form of the names would go away in say one year.
This can be mitigated by providing a macro to enable/disable deprecation warnings. People who don't have time to fix names can use something like BOOST_FS_NO_DEPRECATE (or BOOST_NO_DEPRECATE?) until they get a chance to fix their code. Then you can deprecate basename so accidental misspelling of base_name as basename will result in a warning. -- John