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

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D91311#2398526 <https://reviews.llvm.org/D91311#2398526>, @rsmith wrote:

> [...]

Thanks for your detailed explanation. I did not understand the philosophy of the attribute, and it's now clear to me that it shouldn't be tied to the typedef, indeed.

> There's another design approach we could follow, that would keep the attribute on the template but avoid the awkwardness of requiring the typedef to appear first: we could completely divorce this feature from typedefs. Instead, we could say the attribute is of the form `preferred_name(type, "name")`, where `type` is a specialization of the type to which the attribute is attached, and `"name"` is a name used in diagnostics when referring to that type, which is printed as if it's a member of the enclosing namespace (but there'd be no enforcement that such a member actually exists and declares the corresponding type). What do you think?

I think this is pretty interesting, actually. While it does seem a bit more loosey-goosey in terms of the type system, I can imagine useful applications of being able to use arbitrary strings, such as providing better diagnostics for specific types without having to actually have an associated typedef. Just to clarify, that would look like this, right?

  template<class _CharT, class _Traits>
  class [[preferred_name(basic_string_view<char>, "string_view")]]
        [[preferred_name(basic_string_view<char8_t>, "u8string_view")]]
        [[preferred_name(basic_string_view<char16_t>, "u16string_view")]]
        [[preferred_name(basic_string_view<char32_t>, "u32string_view")]]
        [[preferred_name(basic_string_view<wchar_t>, "wstring_view")]]
  basic_string_view {
      ...
  };

I don't want to ask for something unreasonable.. but I think that's a neat design that's actually more powerful than the current one. I would be curious to hear what other people think as well, to see whether I'm the only one preferring the more free-form approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91311