C++内联命名空间版本控制场景下命名歧义解决方法

问题复现 #

使用inline namespace做库版本控制时，内联命名空间会将内部所有符号导出到父作用域，已知扁平化命名空间、移除inline关键字两种方案均不可行：前者不符合架构设计要求，后者破坏源码兼容性。
初始可正常编译的版本代码如下：

namespace ns {
inline namespace v1 {
namespace detail {
// implementation detail
}
class [[deprecated("use v2::some_class")]] some_class
{
    // ...
};
} // namespace v1

namespace v2 {
namespace detail {
// implementation detail
}
class some_class
{
    // ...
};
} // namespace v2
} // namespace ns

在父命名空间ns下新增同名detail命名空间后，MSVC下触发编译错误，GCC、Clang无异常：

namespace ns {
namespace detail {
class impl {};
} // namespace detail 
} // namespace ns

void f()
{
     ns::detail::impl i; // MSVC报错: 'detail': ambiguous symbol
}

预期行为为ns::v1::detail与父命名空间下的ns::detail自动合并，不产生符号冲突。

标准合规性结论 #

GCC、Clang的行为符合C++标准要求，MSVC的歧义报错属于实现缺陷。
按照C++标准规定：

1. 内联命名空间的成员会被注入父命名空间参与名字查找
2. 命名空间是可扩展实体，所有同名命名空间声明（无论来自直接声明还是内联命名空间注入）都会自动合并为同一个命名空间，不存在二义性。
   MSVC在未开启标准符合模式时，错误将两个来源的detail判定为独立候选实体，才会触发歧义报错。

可行规避方案 #

• 开启MSVC标准符合模式
  新版本MSVC下添加/permissive-编译选项，指定C++17及以上语言标准，即可修复该查找错误，无需修改业务代码。
• 版本化内部实现命名空间（兼容旧版MSVC）
  将各版本内联命名空间中的实现细节命名空间增加版本后缀，避免与父命名空间的公共detail重名，该修改不影响对外API兼容性，旧调用代码无需改动：

  namespace ns {
  inline namespace v1 {
  namespace detail_v1 {
  // v1版本内部实现
  }
  class [[deprecated("use v2::some_class")]] some_class
  {
      // ...
  };
  } // namespace v1
  
  namespace v2 {
  namespace detail_v2 {
  // v2版本内部实现
  }
  class some_class
  {
      // ...
  };
  } // namespace v2
  
  // 父命名空间公共detail不受影响
  namespace detail {
  class impl {};
  }
  } // namespace ns
  

• 显式引导命名空间合并（兼容旧版MSVC）
  在父命名空间中显式声明命名空间合并关系，消除MSVC的查找歧义：

  namespace ns {
  inline namespace v1 {
  // 提前声明detail，和父命名空间的detail显式关联
  namespace detail {}
  }
  // 父命名空间detail中显式引入v1::detail的成员
  namespace detail {
  using namespace v1::detail;
  class impl {};
  }
  } // namespace ns
  

内容的提问来源于stack exchange，提问作者Hedede