nsimd defines i64 etc. in global namespace

[eschnett]

It seems that nsimd defines types i64 etc. in the global namespace (see file nsimd.h, lines 793 ff.). These should probably be prefixed with nsimd_.

[gquintin]

We thought of that during the first drafts of NSIMD. I agree that it is not that good to pollute the global namespace. But when programming in plain C typing nsimd_ each time is not that great and differentiating the C and the C++ APIs (having f32 in plain but not in C++) seems a bad idea too but I am open to suggestions:

for (int i = 0; i < n; i+= vlen(nsimd_f32)) {
  vec(nsimd_f32) va, vb;
  va = vloadu(ptr_a + i, nsimd_f32);
  vb = vloadu(ptr_b + i, nsimd_f32);
  vstore(ptr_dst + i, vadd(va, vb, nsimd_f32));
}

[eschnett]

In C++, they could be in a namespace. Using that namespace would then make it easy to access these types.

In C, there could be a separate include file nsimd_types.h with #defines that would remove the suffix. Alternatively, there could be a #define that either enables or disables this behaviour, depending on the default you choose:

#define NSIMD_GLOBAL_TYPES
#include <nsimd/nsimd_all.h>

This behaviour is not causing a problem for me, but it is somewhat at odds with the otherwise very clean design of the library.

[qukhan]

This also conflicts with C++17 u8 character literal for UTF-8 strings.

We should either prefix these with nsimd_ or put them in a namespace inlined in nsimd that can be pulled with using. The latter would allow using the nice version when possible (I assume most of the time).

void f() {
  nsimd::types::u8 a; 
  nsimd::u8 b;
  {
    using nsimd::types;
    u8 c;
  }
}