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
>>
>