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 ;) Have a lovely day, and thanks for the review! -- Arsen Arsenović
signature.asc
Description: PGP signature
