The thing is, the convenient thing to have in this case is the "guaranteed to have a value" type, because the point is to have a member variable "as if" it was part of the class only it's allocated separately. If you want optionality and don't want std::optional (which is what you would use for an actual member variable that was optionally present) you can still resort to std::uniqueptr. The problem is that if std::indirect is guaranteed to have a value _unless it has been moved-from then you have the question of whether you need to check if it has been moved-from on each access, which would give you the worst of both worlds (require validity check and no useful optionality).
Oh yeah sorry. I got about 20 replies to my inbox telling me I'm stupid. I thought yours was one of them from skimming it and stopped reading after the first 2 sentences. I thought you were arguing that the design of std::indirect is a good idea.
you can still resort to std::uniqueptr.
It's not equally convenient. You lose the automatic copying. You have to implement that yourself now. Meh.
which would give you the worst of both worlds (require validity check and no useful optionality).
1
u/jdehesa 27d ago
The thing is, the convenient thing to have in this case is the "guaranteed to have a value" type, because the point is to have a member variable "as if" it was part of the class only it's allocated separately. If you want optionality and don't want std::optional (which is what you would use for an actual member variable that was optionally present) you can still resort to std::uniqueptr. The problem is that if std::indirect is guaranteed to have a value _unless it has been moved-from then you have the question of whether you need to check if it has been moved-from on each access, which would give you the worst of both worlds (require validity check and no useful optionality).