Support systems that do not support inline namespaces

[michaelsafyan]

The "version.h" file defines "v1" in "opentelemetry::v1" as an inline namespace.

Unfortunately, there are build systems (and companies) with policies that set compiler flags to disallow the use of inline namespaces. It would be ideal if this library could still build on those systems.

I'm not sure whether the solution is to simply remove the "v1" inner namespace or to make "opentelemetry::v1::" more explicit with a bunch of using directives in the outer namespace that create aliases in the "opentelemetry" level for members of "v1". But it would be ideal if this could be built without the use of inline namespaces.

[owent]

Could you please show what's the compiling environment which disallow inline namespace?
inline namespace is a part of C++11 and I didn't find a way to disable it. We required C++11 to build otel-cpp now, and C++14 soon.

[marcalff]

Please check:
https://stackoverflow.com/questions/11016220/what-are-inline-namespaces-for

Asking a library to not use inline namespace is, to say the least, very surprising.

If your company has policies to not use inline namespaces in the (company) application instrumented with opentelemetry-cpp, this is fine, but it should not follow that third party dependencies are prevented to use inline namespaces.

Please name, in details, a build system for which this is an actual issue.

[michaelsafyan]

Use of inline namespaces is indeed reasonable. Unfortunately, Google's internal build system disallows them. But you are right that it is unreasonable for this constraint to apply to other libraries, especially as it is a standard C++ feature and it is apparently not even possible to reproduce the build environment externally as the compiler flags to disallow are proprietary.

I'm going to investigate other internal workarounds (or see if the internal environment can be better aligned with standards, at least when compiling external dependencies).

Please consider this request withdrawn.

[lalitb]

The Google C++ Style Guide recommends avoiding inline namespaces; this could likely be a mandatory rule for code within Google's internal repositories - probably enforced through linting.

Do not use inline namespaces. Inline namespaces, in particular, can be confusing because names aren't actually restricted to the namespace where they are declared. They are only useful as part of some larger versioning policy.

[marcalff]

not even possible to reproduce the build environment externally as the compiler flags to disallow are proprietary

Ah, this makes sense now. Thanks for clarifying this part.

[ThomsonTan]

The Google C++ style Guide also mentioned, which is exactly the usage in this repo.

Inline namespaces are primarily intended for ABI compatibility across versions.