I don't get the issue with "UDLs can't be qualified". The practice, shown
by the standard, is to put decls of UDLs into a namespace by themselves.
Then "using namespace ..." when you want them, so they can be as tightly
scoped as you like or need. You can then import two (or more) different
(sets of) UDLs into a scope where you need more than one, but


   1. is that a common use case? (considering how you might properly use
   procedural abstraction to separate the two domains)
   2. if you *do* have a tight section of code that uses UDLs from two
   different domains is it likely they conflict?
   3. if they *do* conflict and in your use case it is probable (or even
   possible) that you would use them together, then, if you own one (or both)
   of the UDL declarations can you just rename one?
   4. if they *do* conflict and you can't rename one can't you just, for
   that one section of code, use procedural abstraction again to move one (or
   more) of the *literals* out of the scope where both sets are visible?

(Remember it isn't a problem *using* the two domains together, nor using
the two domains together with literals from only one: just using the two
domains together with literals from *both.)*

I just don't see it as a sufficiently large pain point to require a
language change. (I wouldn't have complained if it was specified that way
in the beginning, but why bother now.) Please let me know if my
assumptions about how common these conflicts are are wrong, or if the
ameliorations above aren't sufficient for some use cases that are important
to you.

-- David

On Fri, May 7, 2021 at 7:09 AM Andy Little via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Thursday, 6 May 2021, 15:10:01 BST, Jason McKesson via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> > It can be made available as a template parameter. Unsynthesized UDLs
> > exist; they take the UDL as a variadic sequence of `char`s. They're
> > much harder to parse, but they are functional solutions.
>
> > The simplest solution here (that requires no language changes) is to
> > make a pair of library `consteval` template functions that take the
> > sequence of chars and returns a synthesized value; one for integers,
> > one for floats. This value would be `constexpr`, so it could be used
> > to determine the result type of the function.
>
> Thanks for that. I didn't figure out how this works before.
>
> I did a rough and ready test which I put here for those interested. I
> hope long term to incorporate it into my library properly
>
>
> https://github.com/kwikius/pqs/blob/master/examples/bespoke_user_defined_literal.cpp
>
> ------------
>
> > UDLs are for when space is at a premium, wordiness is really bad, and
> > the resultant meaning of the code ought to be obvious.
>
> Sure, but that is basically always.
>
> > Adding namespaces to literals like this (even if the parser could do it)
> > means that you're willing to spell things out.
>
> UDLs is a potentially nice language feature, but is inflexible. Currently
> UDLs can't be qualified, so they can only be used in global namespace.
> The problem as shown by the ad hoc rule that UDLs without underscore are
> reserved.
> Yet already there are potential collisns in std namespace between units
> libray proposal
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1935r2.html
> and std::chrono literals
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>