I'm aware about the potential pitfalls of userexpr, the main one being how to determine whether t`s value comes from a literal, but i think this could be sorted in a similar way as how std::reference_constructs/converts_from_temporary work from the compiler's perspective; if t's type isn't one of the list declared at https://eel.is/c++draft/over.literal#3, is constructed from a non-literal/temporary, and it's accessed after its lifetime begins(dynamic branches included) and before its usage in the userexpr(the concept of access being defined by https://eel.is/c++draft/intro.defs#defns.access), then the t's usage on a userexpr is ill.formed.

And sure, userexpr could be used for this endeavour, but i don't want to promote it as the main solution until i fully study all of its potential details, that's why my intention was to submit an intermediate detection-feature

El mar, 15 ago 2023 a las 22:19, Jens Maurer (<jens.maurer@gmx.net>) escribió:

On 15/08/2023 20.05, veronica alphonso wrote:
> An example of using this proposed feature(and userexpr, which is another feature yet to propose) would be:

So, you're asking for a new feature to support yet another novel feature.

> template<class R, class T, const char* suffix, bool sized = true>
> requires std::user_defined_literal_r<R, types_to_params<T, std::conditional_t<sized, std::size_t, void>>, suffix>
> constexpr R instantiate_usl(T t)
> {
> return userexpr(t, sized, suffix);
> // userexpr converts the given instance, sized or not, and suffix to its literal representation
> // in the form of an expression
> }

Why can't you use

  requires {  userexpr(t, sized, suffix }

in your concept, then?  All you want to check is whether the given "userexpr"
is valid or not.

(I'm not offering an opinion whether "userexpr" is a good idea to start with.)

Jens

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals