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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
