Date: Tue, 29 Nov 2022 10:55:25 -0600
That's an interesting alternative. Also, could you elaborate on your
concern with dependent templates?
On Mon, Nov 28, 2022 at 11:43 AM Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>>>>
>>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
concern with dependent templates?
On Mon, Nov 28, 2022 at 11:43 AM Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>>>>
>>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2022-11-29 16:55:37