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

Thu Oct 24 11:44:20 PDT 2019

dblaikie added a comment.

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

> In D69230#1718191 <https://reviews.llvm.org/D69230#1718191>, @lawrence_danna wrote:
>
> > Seems like there's a consensus that if we have something like this it should be called `DenseOptional`, and changes to `Optional` should only make it more like `std::optional`
>
>
> I am not sure I would call that a "consensus"  -- my interpretation of @dblaikie's comment is that he does not want an extra dense optional type either. Which I disagree with, because I think it would be useful to have some form of a compressed optional storage, as that's something that is currently often implemented via bitfields, magic invalid values, etc.

Open to disagreement - I don't feel super strongly. Though if we're going to diverge from std::optional & have functionality like this - maybe, yeah, we just rename what we have to "DenseOptional" and use it everywhere. Maybe not even rename it? Maybe we just accept our Optional will be different/better (for us) than the standard one indefinitely?

> That said, I think you have convinced me that having different optional representations for a single type is not a good idea. It's probably better to use some form of a "strong" typedef to achieve that instead.

I've not followed this part of the thread properly - could you/someone rephrase the concerns here?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69230