[libcxx-dev] Providing custom template specialization for std::optional?

[Владимир Гончаров via libcxx-dev]

> Can you explain what your specialization does differently? And why it's needed?


I have a class which is a C++ interface for an object defined in a C library. Internally, it is a pointer which can never be null (if C interface returns null, the class constructor throws).
I want to use this fact to optimise optional's storage. That would allow shrinking optional's size to eight bytes. Since we store a lot of optionals of this class, this change would reduce memory usage by about five percent (I've done some testing).
I really don't want to invent a new optional specifically for this case. I also don't want to allow storing null pointers inside of the original class because this would require an assert before almost any usage of the class.

> I think the standard is being too permissive here.


Maybe it is. But again, if I can provide a more efficient specialization which would utilise some knowledge about the wrapped type, why shouldn't I?

> `<variant>` is a good example.


By the way, providing custom specializations for variadic templates is forbidden =)

Kind regards, Vladimir Goncharov

> On 7 Mar 2019, at 08:39, Eric Fiselier <eric at efcs.ca> wrote:
> 
> 
> 
> On Wed, Mar 6, 2019 at 5:41 PM Владимир Гончаров via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
> Hello!
> 
> I'm implementing a specialization for std::optional for my program-defined type.
> 
> Can you explain what your specialization does differently? And why it's needed?
>  
> As I understand [namespace.std], nothing forbids me from doing that.
> 
> I agree that you've interpreted the standard correctly. But I think the standard is being too permissive here.
> Implementing a complex component may necessitate knowledge of the internals. `<variant>` is a good example.
> 
> I would like to know what other library maintainers think.
>  
> /Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190307/7b6dab21/attachment.html>