unique_ptr is simpler, and can be easily converted to shared_ptr if needed, and makes it obvious that each call will return a new pointer.
This does mean that if I want to hold onto the objects again in the future for some reason, that'll need the API to change back, but that seems unlikely.
unique_ptr not being copyable does make using it a little more awkward, but that only happened in one place in LOOT's code, and there the pointer needs to become shared anyway.
The C++ wrapper defaults it to true, so the behaviour hasn't changed for
existing callers that don't pass a value for the evaluateConditions
parameter, i.e. that call GetGeneralMessages().
Since the new parameter comes before evaluateConditions,
existing GetGeneralMessages(true) and GetGeneralMessages(false) calls
need to be replaced with GetGeneralMessages(true, true) and
GetGeneralMessages(true, false) to retain their existing behaviour. The
parameter order was chosen to match that of GetPluginMetadata(), at the
cost of this backwards incompatibility.
Oliver Hamlet