I think with an opt-in, unignorable syntax this can proposal can work.

Something like template<using enum EnumType value>. Different lookup rules for overloaded function templates can be weird, but I think it can be worked out. My main concern would be dependent templates.

On 28 November 2022 18:15:22 CET, Ryan Klaus via Std-Proposals <std-proposals_at_[hidden]> wrote:
>I think this is a fair criticism. Not sure I necessarily agree with it,
>especially with the bit about it being only a "marginally" improvement for
>the reader as this scales pretty well across all call-sites, but I can see
>how this could potentially make code harder to read if used inappropriately
>(though that can be said about a lot of things in the language). That being
>said, P0028R4 (i.e. "Using attribute namespaces without repetition")
>could've also been rejected on similar grounds of being "not particularly
>motivating to work on". In terms of readability improvements, this proposal
>leaves that one in the dust, in my opinion. Though, as Peter pointed out,
>this does break the ignorable attribute rule, so it's still probably not a
>solid proposal in the current syntax.
>
>On Sun, Nov 27, 2022 at 10:29 PM Andrew Tomazos <andrewtomazos_at_[hidden]>
>wrote:
>
>> I've thought about things like this a few times. Within certain syntactic
>> contexts you want scopes to be implicitly used and not have to fully
>> qualify names repeatedly. For example, the parameters to a member function
>> could be looked up in the scope of the class - and that sort of thing.
>> Also `with` statements from other languages are similar in spirit.
>>
>> Ultimately I think this is an optimization that is better for the writer
>> than the reader. In fact it's arguable that:
>>
>> auto color = ABC::Color<
>> ABC::ColorComponents::RGBA,
>> ABC::ColorComponentLayout::_8888
>> >{};
>>
>> might even be more readable than:
>>
>> auto color = ABC::Color<RGBA, _8888>{};
>>
>> At least it's very clear what RGBA and _8888 are and where they are
>> defined. We shouldn't confuse tersity with readability.
>>
>> Given this is at best marginally better for the reader, it's not
>> particularly motivating to work on. (In case you don't know the design
>> principle: Code is read much more often than it is written, so the reader
>> has a much higher priority than the writer.)
>>
>> Plus with code completion tools in such a good state these days the
>> benefit to the writer is also somewhat mitigated.
>>
>>
>> On Mon, Nov 28, 2022 at 12:40 PM Ryan Klaus via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Let's say I have a template class that takes two enums:
>>>
>>> template <ColorComponents T_components, ColorComponentLayout T_layout>
>>> class Color { ... };
>>>
>>>
>>> Because I'm a good boy, each enum is of course an enum class like so:
>>>
>>> enum class ColorComponentLayout
>>> {
>>> _332,
>>> _4444,
>>> ...
>>> };
>>>
>>> enum class ColorComponents
>>> {
>>> RGB,
>>> RGBA,
>>> ARGB,
>>> ...
>>> };
>>>
>>>
>>> And all of the above is inside the namespace "ABC".
>>>
>>> In a just world, I feel like I should be able to right something like
>>> this:
>>>
>>> auto color = ABC::Color<RGBA, _8888>{};
>>>
>>>
>>> The compiler knows it wants a *ColorComponents *followed by a
>>> *ColorComponentLayout*, so all of the contextual information is
>>> theoretically there.
>>> But this is not a just world and so I'm forced to write this incantation:
>>>
>>> auto color = ABC::Color<ABC::ColorComponents::RGBA,
>>> ABC::ColorComponentLayout::_8888>{};
>>>
>>>
>>> So my proposal is to create some new attribute, [[context(...)]], such
>>> that we could write:
>>>
>>> [[context(using enum ColorComponents, using enum ColorComponentLayout)]]
>>>
>>> template <ColorComponents T_components, ColorComponentLayout T_layout>
>>> class Color { ... };
>>>
>>>
>>> This essentially allows for any parameter list (function or template) to
>>> have using statements scoped only to the parameter list itself. This could
>>> also permit type aliases to allow for context specific parameter list
>>> aliases. Not sure when that would be useful, but I could see that
>>> potentially being a very handy space saver.
>>>
>>> What's everyone's thoughts on this? Is it possible? Is it not possible?
>>> Is it possible but we hate it?
>>>
>>> Thanks,
>>> Ryan Klaus
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>