On Thu, 12 Jan 2023 at 16:17, Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Thu, Jan 12, 2023 at 10:34 AM Federico Kircheis via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> On 2023-01-12 at 11:23, Frederick Virchanza Gotham via Std-Proposals
> wrote:
>
> >
> >Now if you were to ask me . . . . I would almost go so far as to
> >propose that C++26 should deprecate defining a global object that
> >doesn't satisfy 'is_trivial' so that all such objects would be wrapped
> >in an std::optional<T> and emplaced within the body of 'main', but of
> >course I know that I won't get any support on that.
>
>
> It would also not cover most use-cases, for example
>
>
> ----
> /* const */ int i = function_that_throws();
>
> int main(){
> }
> ----
>
>
> Also std::optional as global variable is problematic if inside a
> library, depending on the visibility of the symbols, the destructor
> might be executed more than once (and thus be UB)

It seems to me that, to the extent that this is a significant problem,
static analysis is likely the most effective solution. Static analysis
tools should be able to detect if the initializer for a global is
`noexcept` and there can be options to have such tools give a warning
if it isn't. Better tools might be able to follow inlined functions to
see if anything could actually throw given the value of parameters.

As Lénárd says above, this already exists: `constinit`.

struct X {
    constexpr X(int i) {
        if (i == 99)
            throw i;
    }
};
constinit X x1 = 1; // OK
constinit X x99 = 99; // ill-formed, X::X(99) throws

It's perhaps not quite as useful yet as it might be, but once we get non-transient constexpr allocation (TM) there will be little that you can't do in a constant-initializer.

There's no need for a complex language change. Especially since more
pernicious problems of complex global initialization (the static
initialization order fiasco) also need attention from static analysis
tools. This would just be one more to throw on the pile.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals