Fernando wrote:
[...] But when i store values where the type has an inline NaT value (for example NULL pointers) i cannot and need not use optional.
Can you explain why you cannot use optional<>? I definitely see that you don't need it, but for the sake of genericity I just wouldn't mind the fact that some types do have an identifiable null value and use optional<> all along.
Well i could use it but i do not want to. The space complexity is linear as i have to store it for every entry and a perfect hash could grow alot even for a small number of entries. Further arguments: The interface change would be backward compatible as you add a template parameter which has a default value (indicating the old behaviour). With the change i would have both the more optimal solution and the genericity. My problem is that the implementation of optional is not as trivial as it seems and i cannot wrap the class so i would have to copy and modify the source. And i guess using optional in containers and having both types of values (pointers are a good example for the inline NaT case) is not such a far fetched scenario. In the special case of pointers it would make sense not to have a static member indicating the null value but a Discriminate template parameter having the special value 'class NullPtrTag { };'. Another solution would be to make a detail::generic_optional with all the operator foo and let optional inherit from it. That would be infinitesimal backward-incompatible ;)