> you can still use it with smart pointers provided by any other library Is the point of having a kitchen-sink library like this not that you dont have to reac

> you can still use it with smart pointers provided by any other library Is the point of having a kitchen-sink library like this not that you dont have to reach for a 3rdparty library for things that you need 'all the time'? Certainly, not everyone needs it. ...but, not everyone needs threads either. Not everyone needs an http server; and yet, if you have an application framework that provides them, when you do need them, it saves you reaching for yet-another-dependency. Was that not the point from the beginning? unique_ptr is a fundamental primitive for many, as you see from some other frameworks (1), and implementation is not always either a) trivial, or b) as simple as 'just use std::unique_ptr'. This does seem like a very opinionated decision with reasonably unclear justification; perfectly fair, you're certainly not beholden to anyone to implement features just because they want you to, but I think it's difficult to argue there's not concrete use for something like this, in a way that aligns with the project principals. I would go so far as to argue that: > Do not allocate many tiny objects with their own lifetime (and *probably unclear or shared ownership*) Is hostile to not having a unique pointer. [1] - eg. https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Runtime/Core/Public/Templates/UniquePtr.h https://github.com/EpicGames/UnrealEngine/blob/release/Engin..., https://github.com/electronicarts/EASTL/blob/master/include/EASTL/unique_ptr.h https://github.com/electronicarts/EASTL/blob/master/include/...