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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
