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.