dblaikie added a comment. In D91311#2400775 <https://reviews.llvm.org/D91311#2400775>, @ldionne wrote:
> 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. How would that work for users - they would get error messages from the compiler using type names that don't exist in the source code? I'd have thought that would be quite confusing. > 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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
