On Sun, Mar 16, 2025 at 5:13 AM Yongwei Wu via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On Sun, 16 Mar 2025 at 06:55, Thomas Köppe via Std-Discussion <std-discussion_at_[hidden]> wrote:
>>
>> Thanks a lot to Brian. I think he captured the point very well. I believe we discussed the choice of not having the attribute on members, but I'm afraid that explanation didn't make it into the paper and should have. Indeed, the attribute disables a safety feature, and so allowing it to appear where a user can't reach it would somewhat undermine the attempt to improve safety. The opt-out is still available for situations where a use case warrants it, but it needs to be at place where the relevant variables are declared. Classes for which the opt-out promises significant performance improvements could document that users can benefit from applying the opt-out.
>>
>> One could of course imagine revisiting this decision, but that was the rationale for the status quo.
>
>
> Good to hear the rationale from the author!
>
> This said, I am still very doubtful about this decision. The person who puts in the [[indeterminate]] attribute should be responsible for ensuring the use is good, and the attribute should clearly mark which object does not need to be initialized.
>
> Requiring the client code of a class to use the [[indeterminate]] attribute has obvious disadvantages:
>
> 1. It leaks out implementation details. This is especially significant when the class implementation changes from not using an uninitialized buffer to using one, or vice versa. Imagine (OK, not a real scenario), what would you feel like if an efficient use of std::string requires the use of [[indeterminate]]? (Theoretically, as std::string usually has small object optimization.) Would the current spec actually encourage people to use a vendor-specific attribute to solve the potentially efficiency issue, thus reducing portability?
>
> 2. It does not help to express the purpose of the class writer, i.e., which object is intentionally not initialized and will be initialized later. The [[indeterminate]] attribute could have had the natural ability to express the intention, thus enhancing code readability without requiring additional comments.
>
> I'll repeat my statement: It is far too confusing to mark a class-type object with proper constructors as [[indeterminate]]. It would be extremely counter-intuitive. Potentially, It is something that could be added to the laughable repo of C++ haters, and something that people have to teach and emphasize in C++ books to make people use correctly....
>
> My two cents.

My question is this: how often do you expect [[indeterminate]] to be
used/essential to an application's functionality?

To me, it seems like the idea is that [[indeterminate]] should be
treated similarly to [[likely]] and [[unlikely]]: a highly useful
feature, but ultimately one with niche applicability for people who
are looking *deeply* for performance micro-optimizations, such that
the majority of C++ programmers never need to touch this feature.

If that's how [[indeterminate]] is expected to work, if it's something
that most programmers most of the time won't need to think about, then
I don't think these disadvantages really apply. That is, it is not up
to the implementer of any particular class as to whether or not
[[indeterminate]] is appropriate for the class; it's up to the final
user of that object on a case-by-case basis. They are the ones looking
for that performance benefit, so they are the ones who get to say when
to get it.