[PATCH] D69230: RFC: specialized Optional<T> for T that can represent its own invalid state

Wed Oct 30 18:11:24 PDT 2019

dblaikie added a comment.

In D69230#1727209 <https://reviews.llvm.org/D69230#1727209>, @labath wrote:

> BTW, I was bored on the plane, so I created this proof of concept F10589216: dense.cc <https://reviews.llvm.org/F10589216>. It needs a lot of cleanup of course, but it demonstrates one way to generically store some extra data with some type. It gives each type the option to define a bunch of unused (the patch calls them "free") values (which can be useful for for Optional<>s, DenseMaps, etc.). Also each type can say that it is able to store some extra unrelated bits (like PointerIntPair does), and with a bit of care, one can even nest these types arbitrarily). the main thing I haven't yet figured out is the relationship with DenseMapInfo. Theoretically DenseMapInfo could be implemented on top of DenseInfo, but I am still wondering whether we could not make that a single type (trait) somehow...

Neat - yeah, I'd certainly like to see something along those lines, including unification with/replacement of DenseMapInfo (though DenseMapInfo needs other things like hashing, so I'm not sure we'd necessarily want to replace them - I guess it could be a trait class with "optional" features - no reason an implementation necessarily has to have all 4 functions of DenseMapInfo - but maybe separating it would be better to express intent (DenseMapInfo builds on DenseInfo and adds the requirement for hashing and equality)).

I guess there's an open question to me as to whether DenseOptional should just be the only optional we use, and it could fallback to non-dense when the type didn't provide some extra states - or should it be like DenseMap where you just can't use it and have to use std::map or similar once your type doesn't have extra states? I don't know that I feel super strongyl either way - I don't think we have lots of hypergeneric code that wants to DenseOptional<T> over some unknown T that might have spare bits of state and T that might not.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69230/new/

https://reviews.llvm.org/D69230