https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh File flower/include/file-name.hh (right):
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47 flower/include/file-name.hh:47: std::string root_; On 2020/01/23 11:33:11, lemzwerg wrote: > This is very ugly. I sympathize, but it is unambiguous. > What about using the `std` namespace within a group instead? It is possible to define a type alias File_name::string that can be used as "string" in the body of the class definition, in the parameter lists of File_name member functions (but not in the return values), and in the bodies of File_name member functions. It would look like this: class File_name { using string = std::string; // C++11 // or in the old style: typedef std::string string; ... Of course, you would need to do the same for each type or function that you wanted to avoid qualifying, and you would still have a bad time if you tried to use it in particular cases where it creates ambiguity. In a professional setting, I wouldn't advocate using this technique in such a simple case, but if I had colleagues who loved it, I would put up with it to keep the peace. I'd ask them not to demand that I follow their example in subsystems that were my responsibility. I expect that switching to this style consistently in LilyPond would require an amount of labor that I am not currently willing to devote. Thankfully, it seems the consensus on this patch is starting to point toward "take it" rather than "leave it." https://codereview.appspot.com/579240043/
