If a different compiler breaks this behavior, it's not standard compliant and thus could do all sorts of stuff in every possible line, including in:
std::string pad = "";std::string pad = descriptive_name_here(path);
with the added bonus of being able to add "const" to that, for the benefit of the reader.
This is not relying on compiler implementation! Can you name one language that has strings that initialise to anything but a valid object containing an empty string?
This is not an obscure side-effect. This is like assuming "std::vector<int> v;" creates an empty vector, not a undefined-state vector container.
(I don't want someone coding C++ as if all objects are references. Coding in one language as if it were another is a well-known antipattern)
I ran into this article that puts quite nicely why the problem isn't the "else", but the "if" itself:
https://medium.com/@bartobri/applying-the-linus-tarvolds-goo...
This is what I meant in the other comment by preferring the non-branching.
Good thing then that it's mandated by the language reference, and not up to the compiler to decide. According to C++11, ยง21.4.2/1, an uninitialized std::string should be an object of class std::basic_string with non-null data and a size of 0.
Anyway the reason for which it would no pass review is that today you use one compiler, tomorrow you have to use another and then you have to review all these little details again. It's about saving money more than anything and you do that by not relying on compiler behavior.