On Mon, Nov 28, 2022 at 12:50 PM Ryan Klaus <rfklaus117@gmail.com> wrote:
Yeah, I knew it would be scary, but I braved it anyway because this has been a recurring pain point for me and has often made me reach for less satisfying alternatives or ones with other draw-backs that I'm not willing to incur (macros limit the design/readability in other ways, among other problems).

I think macros are a perfect solution to your specific problem here. There may be other situations where macros would cause problems, but this doesn't seem to be one of them.
I'm not sure what problem your last example is trying to demonstrate though. I'm not sure if there is supposed to be an implied attribute on S? I definitely wouldn't want enumeration values to be automatically deduced without explicit say-so, which is why I proposed the "context" attribute.
Regardless, the point that Peter brought up about ignorable attributes (nice article on that, by the way!) is a good one and alone makes this a less than solid proposal barring some alternative syntax.

Ah, I had completely missed that you were proposing this as only an opt-in syntax. That makes your proposed solution
- much less risky in terms of changing existing semantics, and
- much more well-specified in terms of what semantics you're actually proposing, but
- much much more of a niche case, because now it requires the library author to use some special syntax, and if the library author knew about this problem, they'd simply not introduce the problem to begin with.

For example, a library author who foresaw this use-case and wanted to make the syntax shorter could simply do

    namespace ABC {
        using Color_RGBA_8888 = Color<ColorComponents::RGBA, ColorComponentLayout::_8888>;

and then the use-case for the client becomes simply

    auto color = ABC::Color_RGBA_8888;

This works already in C++11; no need for any attributes or macros or anything. (Although macros could still be helpful to generate all of the Color_X_Y type aliases, depending on how many of them there were.)

A library author who doesn't foresee this use-case simply won't use your attribute, and then (as far as I can tell, now) you're simply proposing that there should be nothing the client can do at all (besides add their own macro or type alias).

It's also worth noting that this is an O(1) problem. The client will write
    namespace My {
        using Color_RGBA_8888 = ABC::Color<ABC::ColorComponents::RGBA, ABC::ColorComponentLayout::_8888>;
in only one place in their entire codebase, so making this line a few characters shorter doesn't really buy us anything that's worth changing a whole language over.