On Tue, 13 Oct 2026 at 13:35, Arsen Arsenović <[email protected]> wrote:
> Hi Jonathan, > > (Will address or fix the rest of the comments later; I'm in the middle > of doing something else, but this is sufficiently simple to answer now) > > Jonathan Wakely <[email protected]> writes: > > > Also, on the topic of "is this part of the standard API needed" ... is > > it necessary for gcc::optional and gcc::expected to be > > trivially-constructible and trivially-assignable when the > > contained types are trivially constructible/assignable? > > > > Maybe the answer's yes (so they can be memcpy'd into vec<> objects or > > something?) but I thought it's worth asking, because if that part of > > the API isn't required, the code could be simpified even further. > > The answer is yes for sake of the efficiency of the generated code. > > FWIW 'optional', and even more so 'expected', are most useful as return > types rather than storage, and indeed the patches that are using them > primarily use them for that purpose. > > One of the concerns raised when I originally proposed the change was the > pessimization of function calls that use 'qualifier_set's (which are now > a struct but were previously 'int' unfortunately). Most of that > pessimization is gone because 'qualifier_set's are trivial to copy/move. > > I'd prefer not to bring it back via oversimplified generic types just to > add an error case ;) > Makes sense - it's worth putting complexity in the internals of optional and expected to make the usage more efficient and straightforward. Thanks.
