[sgsjchs]

> And what's the underlying value of such a default constructed socket? I assume it would be -1 resp. INVALID_SOCKET

No, as explained, the default value would be the result of `::socket` call, i.e. a fresh OS-level socket.

> So you essentially must wrap it in an optional if you want to use it as a member variable.

No, you only must wrap it if you really want this closed state to exist.

> Sure, you can implement a socket class like that, but it's neither necessary nor idiomatic C++.

Obviously. Because the moves are not destructive. If they were, this design would be superior. And the wasted space for optional is solvable, just like for non-nullable pointers.

[spacechild1]

> If they were, this design would be superior.

I see how destructive moves would slightly simplify the implementation, but what difference would it make apart from that? (Don't get me wrong, I totally think that destructive moves are a good idea in general, I just don't see the qualitative difference in this particular case.)

> And the wasted space for optional is solvable, just like for non-nullable pointers.

In the case of non-nullable pointers the library author knows that they can use NULL as a sentinel value and write a corresponding specialization. But what could you possibly do with an arbitrary user-defined class?

[sgsjchs]

> what difference would it make

The same difference as making pointers always non-nullable and reintroducing nullability via an optional wrapper only when semantically appropriate.

> what could you possibly do with an arbitrary user-defined class

Just add some customization points to std::optional so that users can define which value of the class to treat as noneopt internally.

[spacechild1]

> The same difference as making pointers always non-nullable and reintroducing nullability via an optional wrapper only when semantically appropriate.

Again, I don't see what this has to do with destructive moves. If you want a socket class that always refer to an open socket, you can already do that. Same for non-nullable pointer wrappers. Conversely, destructive moves don't prevent you from implementing a socket class with a close() method. These concepts are really orthogonal.

> Just add some customization points to std::optional so that users can define which value of the class to treat as noneopt internally.

How is this supposed to work? The very point of your socket class is that it always contains a valid socket handle. Once you introduce a sentinel value, you are back to square one. If the optional class is able to construct a socket with the sentinel value, so is the user.

[sgsjchs]

> Again, I don't see what this has to do with destructive moves. If you want a socket class that always refer to an open socket, you can already do that.

Technically you can, but it's unreasonable to create an os-level socket just to put into the moved-out object where it will be immediately destroyed again. This is not an issue when the moves are destructive.

> How is this supposed to work? The very point of your socket class is that it always contains a valid socket handle. Once you introduce a sentinel value, you are back to square one. If the optional class is able to construct a socket with the sentinel value, so is the user.

That's not true. The sentinel value need not be exposed in the public interface of the class, it can only be accessible via the customization point of the optional.

[spacechild1]

> Technically you can, but it's unreasonable to create an os-level socket just to put into the moved-out object where it will be immediately destroyed again. This is not an issue when the moves are destructive.

No, the class can use a sentinel value internally only to mark moved-from objects. That's exactly where we actually started the conversation. That's why I said that destructive moves would only somewhat simplify the move operations, but not make a qualitative difference (in this area).

> The sentinel value need not be exposed in the public interface of the class, it can only be accessible via the customization point of the optional.

Since the optional would need to construct an instance with the sentinel value, I thought that the "sentinel" constructor must be public. However, you might be right that one could write a template specialization that contains the template argument as a friend class. In this case you could use a private constructor. Note that the destructor still has to handle the sentinel value... But I guess this is just something you have to accept.

[sgsjchs]

> No, the class can use a sentinel value internally only to mark moved-from objects. That's exactly where we actually started the conversation.

The issue is that the "moved-from" state is exposed to the user when the moves are not destructive. The author of the class has to consider behavior for every method in sentinel state, even when it's just to assert that the state isn't sentinel or "lol it's UB". And the user has to be careful not to accidentally misuse an object in sentinel state. Just like how every time you touch a nullable pointer you have to consider if it can be null and what to do in that case. As long as the sentinel state is exposed at all (via non-destructive move), there is little gain in not providing full support for it. However, with destructive moves the sentinel value either doesn't exist at all or only exists completely internally as an optimization, and all this mental overhead disappears.