Date: Fri, 13 Feb 2026 17:54:15 +0100
On 13/02/2026 17:05, Ell wrote:
> On Friday, February 13th, 2026 at 12:44 PM, David Brown via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On 13/02/2026 10:14, Simon Schröder via Std-Proposals wrote:
>>>
>>> Probably not the most elegant solution, but providing the tag as
>>> template parameter would have zero runtime-overhead.
>>>
>>
>> Yes, I have thought a lot about that.
>>
>> But what is missing there is that there is no way to control the use of
>> a type.
>>
>> If we have a type "irq_disabled" with no public destructor, then the
>> only way I can get a member of that type and pass it on to a restricted
>> function is :
>>
>> irq_disabled irqs_off = disable_interrupts();
>> modify_interrupt_table(irqs_off, new_interrupt_vector);
>>
>>
>> With a template, you can write :
>>
>> using irqs_off = irq_disabled;
>> modify_interrupt_table<irqs_off>(new_interrupt_vector);
>>
>> At no point are you forced to remember to call "disable_interrupts()".
>> You might as well just encode the requirement in the function name
>> (which is a well-established technique, but I hope to do better) :
>>
>> modify_interrupt_table_with_irqs_off(new_interrupt_vector);
>>
>>
>> Even with non-type template parameters rather than type parameters, you
>> can't (AFAICS) enforce the correct usage here.
>
>
> You can do something like this: https://godbolt.org/z/5q3z33nve
>
That is a nice idea - it's a step more indirect than I had looked at,
and gives better control. Thank you for that.
> It's hard to use that to revoke permissions instead of grant
> permissions though.
It is indeed. It's always easier to check if you have something (a
"key"), than to check if you /don't/ have one (at least, not without
run-time overhead).
> On Friday, February 13th, 2026 at 12:44 PM, David Brown via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On 13/02/2026 10:14, Simon Schröder via Std-Proposals wrote:
>>>
>>> Probably not the most elegant solution, but providing the tag as
>>> template parameter would have zero runtime-overhead.
>>>
>>
>> Yes, I have thought a lot about that.
>>
>> But what is missing there is that there is no way to control the use of
>> a type.
>>
>> If we have a type "irq_disabled" with no public destructor, then the
>> only way I can get a member of that type and pass it on to a restricted
>> function is :
>>
>> irq_disabled irqs_off = disable_interrupts();
>> modify_interrupt_table(irqs_off, new_interrupt_vector);
>>
>>
>> With a template, you can write :
>>
>> using irqs_off = irq_disabled;
>> modify_interrupt_table<irqs_off>(new_interrupt_vector);
>>
>> At no point are you forced to remember to call "disable_interrupts()".
>> You might as well just encode the requirement in the function name
>> (which is a well-established technique, but I hope to do better) :
>>
>> modify_interrupt_table_with_irqs_off(new_interrupt_vector);
>>
>>
>> Even with non-type template parameters rather than type parameters, you
>> can't (AFAICS) enforce the correct usage here.
>
>
> You can do something like this: https://godbolt.org/z/5q3z33nve
>
That is a nice idea - it's a step more indirect than I had looked at,
and gives better control. Thank you for that.
> It's hard to use that to revoke permissions instead of grant
> permissions though.
It is indeed. It's always easier to check if you have something (a
"key"), than to check if you /don't/ have one (at least, not without
run-time overhead).
Received on 2026-02-13 16:54:19
