Should conversion operator of v<T> return reference to the underlying type? about libpmemobj-cpp

[pbalcer]

This is modeled after p<> where a conversion operator for a non-const reference would require a snapshot. Such approach would probably lead to many unnecessary snapshots, that's why there are explicit getters.

For consistency sake, v<> behaves the same, and to get a mutable reference, you have to call get(). But... I guess returning a reference would make more sense in this case, since there's no snapshot.

Can we have both though? How would the compiler choose between a conversion to T and T&?

[tomaszkapela]

I don't think you can have both. The compiler cannot do overload resolution for you based on the return type and that is what you are suggesting, right? I'm not up to date on the topic, so sorry if I'm far off with my comment.

There is syntax where the compiler can behave differently for rvalues, but that is not the case here, right?

[vinser52]

Return type is not part of function signature. But if you would like to have both we can have const and non-const versions of the conversion operator:

`operator T &() noexcept
{
return this->get();
}

operator const T&() const noexcept
{
return this->get();
}`

Note, that in my example even const version does not return by value. I am using const reference. It helps to avoid unnecessary copy. Furthermore, type T might have no copy-constructor.

[igchor]

I think in case of conversion to T& it will be ok to have just one non-const conversion operator. After all, T& can be used in context where const T& is required, right?

[vinser52]

@igchor I agree with you. This changes already part of #40

[igchor]

We have already merged this change to master. We also fixed some other issues with v which we found while testing operator T& so you should probably rebase.