On Mon, Nov 28, 2022 at 1:16 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Nov 27, 2022 at 10:30 PM Ryan Klaus via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Sun, Nov 27, 2022 at 9:05 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >>
> >> Template specialization is a thing. The parameters don't have to be
> >> the ones in the primary template.
> >
> >
> > Sorry, but I'm not sure we're on the same page here. I'm aware of
> template specialization, but how would template specialization allow me to
> omit namespaces inside a template parameter list?
>
> It wouldn't. What I'm saying is that the template arguments you give a
> template don't have to be the same ones as the parameters, due to
> specialization. Therefore, the compiler cannot *know* where `<RGBA,
> _8888>` should come from.
>
> Consider the following specialization:
>
> ```
> template <Value1 val, Value2 val2>
> class Color<ToColorComponents(val2), ToLayout(val1)> { ... };
> ```
>
> What if `Value1` is an enumeration that just so happens to have an
> RGBA enumerator? Which enumerator gets used?
>
> Or what if you have this:
>
> ```
> template <typename T, ABC::ColorComponents layout>
> class Color<T::component, layout> { ... };
>
> struct RGBA
> {
> static inline constexpr ABC::ColorComponents component = ...;};
>
> Color<RGBA, _8888>
> ```
>
> Which one gets used?
>

 Correct me if I'm wrong, but don't the current disambiguation rules for
using statements cover this?

These conflicts could occur with using statements already allowed in the
language.
Here's an example:

enum class ColorComponents
{
    RGBA = 7
};

enum class ColorComponents2
{
    RGBA = 42
};

struct RGBA {};
int main ()
{
    using enum ColorComponents;
    //using enum ColorComponents2;
    // ^ compilation error

    //static constexpr ColorComponents RGBA = ColorComponents(42);
    // ^ compilation error

    struct RGBA x; // Removing "struct" makes this ambiguous
    auto y = (struct RGBA){}; // Removing "struct" makes this ambiguous
    ColorComponents z = RGBA; // Okay

    return (int)RGBA + (int)z;
}


Attempting to use two enums that have the same enumerator name results in a
compile error, and theoretically my proposal would work in the same fashion
as this makes no sense.
Similarly, types can either be disambiguated through a variety of means or,
when not properly disambiguated, throw a compile error. Again,
theoretically my proposal would work in this way.

There are some other issues with my proposal that others have pointed out,
but I think this one can already be dealt with using
already established rules.

Let me know if I'm missing something.

Thanks,
Ryan Klaus