[libcxx-commits] [PATCH] D91311: Add new 'preferred_name' attribute.

[Richard Smith - zygoloid via Phabricator via libcxx-commits]

rsmith added a comment.

In D91311#2400998 <https://reviews.llvm.org/D91311#2400998>, @dblaikie wrote:

> In D91311#2400926 <https://reviews.llvm.org/D91311#2400926>, @ldionne wrote:
>
>> For instance, I can easily imagine a library that provides an API where some types shouldn't be named (for example expression templates). In that case, you might want to describe a type by a string along the lines of `decltype(some-expression)`, which could potentially be a lot more useful than the ability to refer to a typedef. Does this sort of usage ring true to someone else?
>
> A concrete/real-world example might be helpful, if you happen to have one on hand.

I can imagine something like this being useful. But I think we would want a substantially more powerful mechanism to produce those strings. For example, suppose we have an expression template library for matrices:

  template<MatrixType a, MatrixType b> detail::mul<a, b> operator*(a, b);
  template<MatrixType a, MatrixType b> detail::add<a, b> operator+(a, b);

... then given `Matrix3f a, b`, we might want the type of `a * b + a` to be printed as something like `decltype(Matrix3f() * Matrix3f() + Matrix3f())` rather than as `detail::add<detail::mul<Matrix3f, Matrix3f>, Matrix3f>` (and in practice the types of expression template intermediaries tend to be a lot more complex than this). If we had a way to ask for a type to be pretty-printed as a string, we could imagine:

  template<MatrixType a, MatrixType b>
  struct [[clang::preferred_name(mul<a, b>, "decltype(" + sample_expr_of_type<mul<a,b>>() + ")")]] mul { ... };

... for some suitable function `sample_expr_of_type`. I don't think we're there yet -- this would require substantially more compile-time power than we have (formatting type strings, and string concatenations resulting in something that we can then feed back into the attribute). So I don't think a proposal that lets us only include string literals as the second attribute argument really gets us where we'd want to be. (This would also require a new kind of delayed attribute parsing: we would need to delay parsing the attribute argument until after `mul` is declared and in scope -- or we would need to require the template to be declared twice as we currently do.)

While we might not be ready for this right now, going from `[[preferred_name(type)]]` to `[[preferred_name(type, spelling)]]` would be a compatible extension if we wanted to do that in the future.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91311/new/

https://reviews.llvm.org/D91311