4 ms·

That just sounds like a different thing with the same name. It's nowhere close to the purpose of std::monostate.

eequah9L 2y ago
Yeah. The design pattern sounds like there is one state, and it is shared. What STL has looks like, all instances look the same, hence only one state is possible. They are homonyms with slightly different etymologies.
layer8 2y ago
That’s the GP’s point. It is strange that std::monostate was chosen as the name, given that the different Monostate pattern [0] was fairly well established in C++ circles. [0] https://wiki.c2.com/?MonostatePattern https://wiki.c2.com/?MonostatePattern (originally discussed in http://ftp.math.utah.edu/pub/tex/bib/cppreport.html#White:1996:ADU http://ftp.math.utah.edu/pub/tex/bib/cppreport.html#White:19...)
- quietbritishjim 2y ago
  I considered that, but a lot of their comment seems to be about changing the class's behaviour to reflect the functionality they were expecting, rather than just giving it a different name. Especially this bit: > I would've thought that the C++ template class would be just a marker interface to use on a monostate, so that users of the class know that it has shared state. Also, if that's what they really meant then they surely could've have written a far sorter comment that simply says this name is already taken and it should be called something else. They don't seem to be saying that at all. (Not that it affects my original point, but FWIW that linked meaning of monostate isn't common in my experience, and it sounds like a truly awful idea: if your state is really good then be honest about it and use free functions. So it hardly seems worth reserving a useful word for it over the concept std::monostate is actually about.)
  - deleted 2y ago
    [deleted]
- quietbritishjim 2y ago
  BTW I saw your deleted reply about the point of monostate, thanks. For something that has to implement an existing interface, I can see the possible benefit.
  - layer8 2y ago
    Yeah I actually haven’t used the pattern much myself, so I started to doubt the relevance. Once you start having multiple separate monostates implementing the same interface, and also limit their creation/instantiation in the sense that the code that uses the monostate objects is separate from the code that creates them, the difference to regular objects/classes becomes a bit murky.

Yeah. The design pattern sounds like there is one state, and it is shared. What STL has looks like, all instances look the same, hence only one state is possible. They are homonyms with slightly different etymologies.

layer8 2y ago

That’s the GP’s point. It is strange that std::monostate was chosen as the name, given that the different Monostate pattern [0] was fairly well established in C++ circles. [0] https://wiki.c2.com/?MonostatePattern https://wiki.c2.com/?MonostatePattern (originally discussed in http://ftp.math.utah.edu/pub/tex/bib/cppreport.html#White:1996:ADU http://ftp.math.utah.edu/pub/tex/bib/cppreport.html#White:19...)

quietbritishjim 2y ago
I considered that, but a lot of their comment seems to be about changing the class's behaviour to reflect the functionality they were expecting, rather than just giving it a different name. Especially this bit: > I would've thought that the C++ template class would be just a marker interface to use on a monostate, so that users of the class know that it has shared state. Also, if that's what they really meant then they surely could've have written a far sorter comment that simply says this name is already taken and it should be called something else. They don't seem to be saying that at all. (Not that it affects my original point, but FWIW that linked meaning of monostate isn't common in my experience, and it sounds like a truly awful idea: if your state is really good then be honest about it and use free functions. So it hardly seems worth reserving a useful word for it over the concept std::monostate is actually about.)
- deleted 2y ago
  [deleted]
quietbritishjim 2y ago
BTW I saw your deleted reply about the point of monostate, thanks. For something that has to implement an existing interface, I can see the possible benefit.
- layer8 2y ago
  Yeah I actually haven’t used the pattern much myself, so I started to doubt the relevance. Once you start having multiple separate monostates implementing the same interface, and also limit their creation/instantiation in the sense that the code that uses the monostate objects is separate from the code that creates them, the difference to regular objects/classes becomes a bit murky.