Personal opinions about whether UDLs are a prettier syntax for some or other purpose are interesting but not relevant.
UDL's were already considered and accepted as a C++ feature in the standard in form of time UDLs for h min s ms us ns. I and many others find these useful
https://os.mbed.com/docs/mbed-os/v6.10/apis/thisthread.html

I can of course define my own udls _h _min _s _ms _us _ns

However, since UDL's can't be qualified, they will eventually collide with someone else's. This already occurred between std::chrono and potential std units libraries. This also occurs already when I seek to interop with other units library outside std.
units is just one example in the domain I have many years of experience in, but no doubt there are many others in other domains

Sure it is inconvenient to have to be explicit about the qualifying namespace of the UDL you are using, but it should at least be possible and it should also be possible to look up overloaded UDLs without qualification or using statements in various contexts

#include <iostream>
#include <chrono>

int main()
{
   auto a = std::chrono::milliseconds{5};
   auto b = a + a; //this works fine
   auto c = a + 5ns; // so why not this?
}

    On Sunday, 16 May 2021, 15:46:17 BST, John McFarlane via Std-Discussion <std-discussion_at_[hidden]> wrote:
 
 On Fri, 7 May 2021 at 15:09, Andy Little via Std-Discussion <std-discussion_at_[hidden]> wrote:

> 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.


Agreed. If what you're trying to express is rich, expect a few more keystrokes. I'm not convinced -- given how compact they already are -- that UDLs are particularly good at conveying much information. E.g. you need to already know that `sv` means string view. UDLs are not an accessible point of discovery about a type, but an abbreviation to be introduced rarely and used often.


> 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


The namespace collisions aren't as severe as the limit of one suffix per literal. This reduces expressivity so much that -- even in places where you'd really like to see them -- UDLs should be few. We'd all love the "2.6cm" from our school textbooks to translate to code, but textbooks aren't strongly typed.

Units are a good example. A generally-useful units library exposes the rep type in the API of its wrappers: you may wish to use a non-fundamental type, or otherwise control how the number is held. If you try to express a combination of details, you're already in trouble at "an int representing metres" versus "a float representing seconds".
For this reason I recommend against defining UDLs for units at all. Providing the user with a solution that works in toy examples but doesn't scale might be worse than nothing at all. The `299'792.458L * my::km / my::s` approach seems more promising to me.

Cheers,
John

-- 
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion