Fair enough, I get your point. Thanks or sharing your opinion about this.

Thank you for your reply. I think I disagree. I think the pointer semantics that stem from using *myWrappedValue. or myWrappedValue-> will hurt at least as much as the .get() actually, though I do see your point about .get(). So no, I think I’d keep the value semantics and provide something like an an unwrap() or .value() instead.

From a naming perspective, I’d say that using operator* and operator-> are fine, because they represent a conventional access to the value (stored in the smart pointer for example). Contrary to .get() which represent a unconventional access.

Downside is that this of course breaks the value semantics of the type, and instead switches to pointer semantics (as smartpointers are *designed* to model).

Ok, interesting point. Thanks for sharing Vincente!

Same as adding SeatId.get() and FIlmid.get() as the underlying type is still int. You could always implement Seatid and Filmid as full class’s with the required operator overloads…….

And you would be able to add SeatId and FilmId 🙁
I want the compiler prevent me from ths kind of mistakes also.

unique_ptr::get give you access to the pointer but you can not change it while your strong-type::get() allow you to modify the value. Your ::get is more like the operator*() when we see a smart_pointer as a handle of a pointee.

std::get for tuple and variant was an error. We should had tuple_get() and variant_get() or something else.

IMO, the name we want for wrapper types is underlying(). We have already that C++ scoped enums are strong types wrapping an underlying type. We are able to cast an enum over an integral type, and in particular to its underlying type, but we cannot update the value via a reference by using static_cast (https://wandbox.org/permlink/amJwtz9IBEWhrpY7).

Now the question is if we want that the access to the underlying type is by reference or by value. If the strong-type needs to ensure some constraints, it is better to don’t provide a mutable access, and so the function we want return the value, and then, yes, we could reuse the ::get() function.

value() is closer to your strong-type::get. And yes, value() is already used to mean something that can throw.
I can life with a value that can throw because maybe there is no value and with one that always succeed, but having a different name seems better to me.

Yes, that would work, and solves the problem of choosing a good name, since there wouldn’t be one to choose to begin with! On the other hand, implicit conversions are controversial because they are harder to follow, because they don’t show in code, and have the reputation to lead to subtle bugs. It’s a trade-off anyway.
Thanks for your input.

Would this work?