Considere as seguintes afirmações sobre a decomposição do caminho, em que cada variável local, por exemplostem tem a inicialização óbvia, por exemploauto stem = path.stem() —

assert(root_path == root_name / root_directory);
assert(path == root_name / root_directory / relative_path);
assert(path == root_path / relative_path);

assert(path == parent_path / filename);
assert(filename == stem + extension);

Tudo isso funciona, exceto a última linha - porquefs::path não define umoperator+. Temoperator+=, mas nãooperator+.

Qual é a história aqui?

Eu determinei que posso compilar esse código adicionando meu própriooperator+. Existe alguma razão para não fazer isso? (Observe que isso está no meu próprio espaço de nome; não estou reabrindonamespace std.)

fs::path operator+(fs::path a, const fs::path& b)
{
    a += b;
    return a;
}

Minhas únicas hipóteses sobre o assunto são:

Talvez os designers tenham preocupadooperator+ seria facilmente confundido comstd::stringéoperator+. Mas isso parece bobagem, já que faz exatamente a mesma coisa semanticamente (então, por que se importar se for confundido?). E também parece que os designers não se preocuparam com a confusão dos novatos quando criarampath.append("x") fazer algo semanticamentediferente destr.append("x") epath.concat("x") fazer algo semanticamenteo mesmo Comostr.append("x").

Talvezpathconversão implícita deoperator string_type() const causaria alguma variedade dep + q tornar-se ambíguo. Mas não consegui chegar a nenhum desses casos.