On Mon, Nov 28, 2022 at 12:50 PM Ryan Klaus <rfklaus117_at_[hidden]> 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.

–Arthur

>