higher-performance wrote: I see, thanks for explaining. That would be great if you can discuss it offline in the near future.
In the meantime, let me just emphasize a some points from my side before I forget: - The question of delayed initialization is (so far as I can tell) entirely orthogonal to the question of what the standard library should be doing here. If we keep the current spec, then obviously the existing behavior is buggy, and this PR is required for the fix. If we _do_ relax the attribute to allow delayed initialization, then it would require dataflow analysis out of the standard library (since it would now be okay to do `std::construct_at(...)` followed by filling in the fields). Either way, I struggle to see how treating the standard library differently would solve anything. - Insofar as the current spec goes -- just as `std::construct_at` cannot possibly detect (let alone try to avoid) an in-class member initializer that goes awry when invoked, I think it also cannot (and should not) try to avoid the same issue w.r.t. this attribute. It simply does not have enough information, and this is true for every function out there that constructs a user-specified type (`emplace_back`, etc.), not just those in the standard library. https://github.com/llvm/llvm-project/pull/141133 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
