I acknowledge that this problem is a pain. You can also use DYNO_STRING(foo) instead of "foo"_s. Does that solve your problem, or are you set on using the UDLs but just want a less generic one?

I'd definitely prefer the UDL over the macro. The macro feels like a significant step backwards considering how cutting edge this library is.

Seeing as the macro actually has similar namespacing issues (worse, of course, due to the global namespace pollution not being opt-in) which are solved with a C-style DYNO_ prefix, I think it would make sense for the UDLs to follow the same approach. At least until the language is fixed in this respect.

Would you suggest the dyno::literals namespace be dropped in that case?

I've made the change of _s to _dyno on a branch locally and it's a trivial change for me to make. The only thing keeping me from pushing it is that it's uglier to write "some_method"_dyno than "some_method"_s.

Would you suggest the dyno::literals namespace be dropped in that case?

no because if the UDL is defined inside only the dyno namespace the user is required to do a using namespace dyno in a header file to be able to create a public interface.

i don't think _dyno is that ugly tbh.