Public identifiers should have a prefix to avoid name clashes

[ecorm]

Public identifiers (extern functions and public enumerators) should have a prefix to avoid name collisions with user code and other libraries.

Extern functions should have a prefix such as ryu_.

The ryu_parse Status enumerators should have a prefix such as RYU_ or RYU_STATUS_ to avoid clashing with macros as well as identifiers in the global namespace. The SUCCESS enumerator is particularly susceptible to conflict.

[ecorm]

@expnkx Why not? C doesn't have namespaces, so there is no other mechanism to prevent name clashes.

d2s, f2s, and d2exp are very short, and SUCCESS is very common. They are vulnerable to name clashes with user C code and other C libraries.

[ecorm]

You can clone that and put it into the namespace. It all depends on you.

That presumes the user of this library is using C++ and not C. It also makes it impossible to use the existing Bazel script to build this library (compiled symbols will not be in the desired namespace).

I don't want to have to fork this library to make it usable in a large project where name clashes are likely.

BTW, shared linking seriously harms the performance and security of computer.

The library can be statically linked, if desired. I doubt inlining the public library functions makes a significant performance difference versus static linking. These aren't small functions we're talking out.

[ulfjack]

Yeah, they should probably be prefixed. The code is now part of MSVC and (soon?) libc++, and gets prefixed on import there. However, if you want to use it directly, it's a bit annoying that it can cause name conflicts as-is.

[ecorm]

My motivation is to use ryu as a substitute for std::from_chars and std::to_chars on compilers that don't support them.

[ecorm]

I don't know if the goal of this project is to provide a library for general use, or to serve as a reference for other Ryu implementations (or both). Please let know.

I could hide the ryu symbols within a separately compiled unit, but that would preclude the possibility of making my C++ library header-only. For better or worse, header-only C++ libraries are popular due to their ease of integration. Mine would be optionally header-only, and could be compiled separately if desired.

To avoid breaking the existing API, you could provide alternate headers that have the prefixed versions of functions and other symbols. The prefixed functions would simply delegate to the non-prefixed versions. The extra indirection should be optimized away.

[ulfjack]

I'm ok with breaking the existing API.