What's the point of std:monostate? You can't do anything with it

https://devblogs.microsoft.com/oldnewthing/20240708-00/?p=109959

by luu • 2 years ago

115 176 2 years ago

devblogs.microsoft.com

pavlov• 2 years ago

There’s a secret competition between C++ and JavaScript to come up with more variants of nothing.

ThrowawayTestr• 2 years ago

Mathematicians got nothing on lazy programmers

immibis• 2 years ago

VBA has 4 kinds. Null, Nothing, Missing, and Empty.

shadowgovt3• 2 years ago

If you like that, you'll love how many ways you can test for equality in LISP.

MathMonkeyMan2• 2 years ago

That always chafed me about Scheme. I see the utility of `eq?` and `eqv?`, but I'd prefer that there were only `equal?` and functions were defined to get an object's "id" or "numeric equivalency class," or whatever, instead of having different flavors of data structures that differ only for certain values.

koito172• 2 years ago

Each equality function, at least in Common Lisp, has a distinct goal.

Numbers use = if you don't care about type. For instance, the real number 0 and the complex number 0 + 0i would be treated equal by this function.

Do you care about strict pointer equality? eq.

Do you want to distinguish 0 and 0d0? eql.

Do you care about isomorphism? equal.

The only weird function to me would be equalp, given that it performs case-insensitive comparison of characters etc. Overall, I find complaints about the equality predicates to be based on a misunderstanding of the definition of "equality".

Clojure goes the opposite direction and has a single = function that performs all sorts of reflection and deep comparisons; it's convenient in practice, but it's also easy to burn CPU cycles if you are e.g. comparing large collections and only care about pointer equality.

DonHopkins4• 2 years ago

https://news.ycombinator.com/item?id=40192911

DonHopkins 85 days ago | parent | context | favorite | on: What if null was an Object in Java?

Why stop at null, when you can have both null and undefined? Throw in unknown, and you've got a hat trick, a holy trinity of nothingness! Of course the Rumsfeld Matrix further breaks down the three different types of unknowns.

https://en.wikipedia.org/wiki/There_are_unknown_unknowns

"Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones." -Donald Rumsfeld

1) Known knowns: These are the things we know that we know. They represent the clear, confirmed knowledge that can be easily communicated and utilized in decision-making.

2) Known unknowns: These are the things we know we do not know. This category acknowledges the presence of uncertainties or gaps in our knowledge that are recognized and can be specifically identified.

3) Unknown unknowns: These are the things we do not know we do not know. This category represents unforeseen challenges and surprises, indicating a deeper level of ignorance where we are unaware of our lack of knowledge.

And Microsoft COM hinges on the IUnknown interface.

https://en.wikipedia.org/wiki/Tony_Hoare#Research_and_career

Speaking at a software conference in 2009, Tony Hoare apologized for inventing the null reference:
"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years." -Tony Hoare

https://news.ycombinator.com/item?id=19568378

"My favorite is always the Billion-Dollar Mistake of having null in the language. And since JavaScript has both null and undefined, it's the Two-Billion-Dollar Mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg

dunham• 2 years ago

"My favorite is always the Billion-Dollar Mistake of having null in the language. And since JavaScript has both null and undefined, it's the Two-Billion-Dollar Mistake." -Anders Hejlsberg

Assuming these mistakes are additive and not multiplicative.

ackfoobar5• 2 years ago

Throw in unknown, and you've got a hat trick, a holy trinity of nothingness!

`unknown` is a top type, since we're on the topic of nothingness it'd be remiss to not mention its dual, `never`.

The pair is also called `Any` and `Nothing` in some other languages.

loa_in_• 2 years ago

It's probably more of use to compiler/runtime developers than end users if the language.

jcelerier5• 2 years ago

It's useful whenever you want a variant with a default state which is different from any value you'd actually put it it, to differentiate between e.g.

    std::variant<int, whatever> v;
    // v is zero

and

    std::variant<int, whatever> v = 0;

And don't want to pay the space and time overhead of wrapping in an std::optional which will use a whole other byte at least for not good reason

glitchc2• 2 years ago

And don't want to pay the space and time overhead of wrapping in an std::optional which will use a whole other byte at least for not good reason

This. monostate's behavior should be captured in the std::optional spec. There's no need to create a new type.

ryukoposting3• 2 years ago

Parton my naiveté, but if you wanted a value that's either a thing, or not-a-thing, why wouldn't you express that with a std::optional? What advantage does std::monostate have versus option types?

Brevity, I guess? I suppose the most brief way to express absence or presence of value in C++ is a pointer, but I could be tried at the Hague for that take.

None of this is to be facetious, I'm really trying to learn here. I'm not a C++ guy by trade. C and Rust are my day-to-day languages.

masklinn8• 2 years ago

That… doesn’t make any sense?

The size of an optional<T> is `sizeof T + 1` because it needs a boolean for the set/unset flag.

The size of a variant is… the same, at least, because it needs to store a discriminator integer (apparently both gcc and clang do optimise to a byte when there are less than 256 variants).

Or do you mean adding a monostate to an existing variant rather than wrap that variant into an `optional`? In which case you should fix your example (and provide a version wrapped in an optional) because they’re very confusing.

jandrewrogers2• 2 years ago

It has other uses for end-user developers. For example, when you need a class member to be conditionally elided based on template parameters. You can swap the normal type with non-zero size with std::monostate such that it has zero size.

tpolzer3• 2 years ago

A std::monostate member will still have non zero size, because it needs a unique address.

See https://en.cppreference.com/w/cpp/language/ebo

ramon156• 2 years ago

So the upside is that you can put it at the beginning of a function? Wild, bro

Joker_vD8• 2 years ago

You can also use it in any template without any trickery unlike void, which I am willing to bet was the actual rationale.

meibo• 2 years ago

The article describes that as the main advantage, showing std::variant as an example.

Smaug123• 2 years ago

Having access to the unit type is useful; I use it maybe once every couple of months in F# even if we restrict solely to the use-case "instantiate a generic with the unit type to indicate that no data is held here". (Of course, since F# also doesn't have a `void` type - a truly non-constructible data type is indeed very rarely useful! - F# uses `unit` in many places where C++ and C# use `void`.)

lloydatkinson• 2 years ago

So it appears this follows the terrible C++ "naming things with the wrong name on purpose" trend, with the biggest example being naming a variable length array (a list, collection, etc) `std:vector` even though Vector was already a well known word with a very different meaning.

The word/type they wanted for this was the Unit type: https://en.wikipedia.org/wiki/Unit_type and in that list it even states the `std:monotype` is a Unit.

codeflo2• 2 years ago

Functor is one of the worst offenders IMO. In C++ lingo, it simply means "callable object".

halayli2• 2 years ago

In C++ lingo they are called function objects or callables, not functor. You might stumble on code here and there that suffix a class name with Functor but it's not that common.

layer83• 2 years ago

It's not like anyone has a monopoly on the term: https://en.wikipedia.org/wiki/Functor_(disambiguation)

The C++ usage was introduced by Jim Coplien in his 1992 book as a succinct name for an architectural pattern in C++: https://archive.org/details/advancedcbsprogr00copl/page/166/...

sham1• 2 years ago

I'd argue that unit would be just as cryptic as monostate, if you don't know what either is.

Like, if we assume someone looking at code with `std::unit`, what might they think this is? If one is not aware of its use in ML or similar, it could just as easily be assumed that it could be something to do with units like meters or kilograms or whatnot. After all, the C++ standard library is vast so it wouldn't necessarily be all that far-fetched.

Then the only question would be to ask why it would be default-constructible. At which point you'd have to read the docs for the type anyway.

mananaysiempre3• 2 years ago

It’s called “unit” because it is a unit of the operation of multiplication / constructing a tuple (up to a unique isomorphism): for any type 't the tuple types unit * 't and 't * unit are isomorphic to 't. When you don’t have that as a fundamental operation in your type system, like ML does, then it could be confusing.

omnicognate3• 2 years ago

There is indeed a units library [0] aiming for standardisation in C++29.

[0] https://github.com/mpusz/mp-units

lmm5• 2 years ago

I'd argue that unit would be just as cryptic as monostate, if you don't know what either is.

And if my grandmother had wheels she'd be a bicycle. Of course if there wasn't a standard name for this concept that had been used in the industry for 50+ years (and in theoretical work for over 100) then it wouldn't make any difference what name you used for it. But given that there is a standard name for this concept that has been used in the industry for 50+ years, making up a different name is pretty unfortunate.

Scubabear68• 2 years ago

My guess is the maintainers of C++ keep making it more and more awful in an attempt to force people to more sane languages.

But to their dismay the crazier it gets, the more some people dig in and embrace it even more.

/sarcasm. I think.

andersa• 2 years ago

It's not sarcasm. The maintainers have completely lost the plot.

atoav• 2 years ago

Coming from other languages I noticed this about C++ as well. I can't give examples right now but I recall multiple times being like: "Oh that is just a weird name for $KnownComputingConcept".

halayli2• 2 years ago

The term "vector" represents an ordered collection of elements(ex 3-dim vector is [x,y,z]). A list is flat out incorrect because it is used to refer to linked list(std::list), and a collection means a group of objects and that can be anything like a map, set, etc so it's too generic.

Before C++ popularized the term, other programming languages and libraries had already used "vector" to describe similar data structures. For example, Common Lisp has a vector type that represents a one-dimensional array.

Maxatar4• 2 years ago

Stepanov introduced the term in C++ and he fully acknowledges that it was a bad name and that he regrets it. If he could redo it, he would have renamed it array or array_list.

Interview with him acknowledging this:

https://www.youtube.com/watch?v=etZgaSjzqlU

Y_Y2• 2 years ago

It doesn't help that mathematics and physics have their own overlapping but unequal definitions of "vector".

yndoendo• 2 years ago

Reactive style programming also takes the Unit as the value to act upon when the value and the type does not actually matter and only the action does.

https://stackoverflow.com/questions/54336641/is-there-any-re...

gpderetta7• 2 years ago

Consider ML appropriating the term tensor...

nmeofthestate• 2 years ago

Another use of std::monostate is as a special "unset/don't care" value for a template parameter. eg

    template<typename T = std::monostate>
    class C
    {
        ...

        if constexpr (!std::is_same_v<T, std::monostate>
        {
            // T-related behaviour here
        }
    };

ot2• 2 years ago

You can use void for that.

Maxatar4• 2 years ago

void could be an actual meaningful type for a template rather than a dummy type.

klyrs• 2 years ago

I greatly prefer tag classes for this. You can define 'em in a single line and a downstream user can't accidentally plug the unset value in to the template.

amne• 2 years ago

so "std::nothing" was taken? or "std::none" ? or anything else that would make it obvious this type is a fancy way to say void?

rwmj• 2 years ago

Or "unit" in ML-derived languages and Haskell.

fire_lake• 2 years ago

I always think of unit as one - it has exactly one possible value.

Void doesn’t exist in ML

masklinn8• 2 years ago

“Nothing” can easily be interpreted as an uninhabited type (regardless of its use in haskell).

a fancy way to say void?

Less fancy and more workable. Had void been a proper type in the first place it would not have been needed (but also… void had the same issue as nothing, it sounds like an uninhabited type more than a unit type).

Despite that, they could have called it Void, even if the standard library normally uses all lowercase.

ackfoobar5• 2 years ago

Capital letter `Void` reminds me of how Java uses the object type `Void` for this purpose, as all reference types allow null.

proaralyst2• 2 years ago

Void is different from this type though, as a variable of type void can't be occupied.

In ML and friends monostate is called unit (and gets used a lot because void returns aren't allowed by the languages). Some have empty types too, which can never be occupied. A function returning Empty can't return, for example, though there are other use cases

cvoss• 2 years ago

You are equivocating on the word "void". Your statement that "a variable of type void can't be occupied" is true in functional languages where "void/Void" is often used as the name of a type that isn't inhabited (assuming the language is sound/normalizing/whatever).

But here we are talking about C++, where "void" is a pseudotype that is absolutely inhabited, in some conceptual sense. Any function that is declared to return void and which returns is returning a thing that conceptually inhabits void. In this sense, std::monostate indeed captures the same concept as void, but in a much better way, because it's properly a type, not a pseudotype.

Note: Java does the same thing, effectively, with "Void" which is inhabited by exactly one value: null.

kevinventullo• 2 years ago

I think there is exactly one equivalence class of instances of std::monostate, whereas there are exactly zero equivalence classes of instances of void.

In category theory terms, I believe void is the initial type (there is exactly one morphism from void to any other type), whereas monostate is the terminal type (there is exactly one morphism from any other type to monotype).

rerdavies4• 2 years ago

std::void_t would have been nice.

revskill• 2 years ago

Is it like a singleton without any method ?

masklinn8• 2 years ago

Since it doesn’t have any data either (hence monostate) that’s not a useful distinction. It’s a singleton in the same way 1 is a singleton.

formerly_proven3• 2 years ago

Seems almost intentionally confusingly written. Why not use void if monostate is like void? Ah, because monostate is actually entirely unlike void. void has zero values, mono state exactly one.

leni536• 2 years ago

You can have as many monostate objects as you want.

mananaysiempre3• 2 years ago

void is kind of strange in C, because it looks like an empty type, but it still behaves as though it has a single instance (a unit type). For example, a function with an empty return type can’t return (it’d have to supply a value of it); a void function can. You can’t cast things to an empty type (otherwise you’d get a value of it), you can cast things to void. Void a unit type, not an empty type, it’s just a bad one.

formerly_proven3• 2 years ago

It would be somewhat more cohesive and less weird if we'd argued that the "void" return type means that a return value cannot be constructed which is taken to mean that the function has no return value, and simply returns without providing a value.

Joker_vD8• 2 years ago

Because you can't use void in templates uniformly: you can't have "T x;" when T = void, you can't do "return T{};", you can't form types like "(*R)(int, T)", etc.

tpolzer3• 2 years ago

What's really weird to me is not that C++ has a unit type and picked a weird name for it (that's just C++). The weird thing is how many unit types it has:

- std::nullopt_t

- std::nullptr_t

- std::monostate

- std::tuple<>

And I'm sure there's more.

bombela• 2 years ago

What about "void"?

tines2• 2 years ago

void isn’t a unit type (inhabited by a single value), it’s a “bot” type, I.e. no values inhabit it.

omnicognate3• 2 years ago

The distinct types are the whole point. You wouldn't want a std::tuple<> to be implicitly convertible to a std::optional<T> (for arbitrary T), and std::nullptr_t exists to be the type of nullptr, which captures the conversion behaviours appropriate for null pointer literals and has nothing to do with the variant use case std::monostate exists to serve.

tpolzer3• 2 years ago

If there was a std::unit_t and it was implicitly convertible to optional, tuple and pointer, I don't think that would be worse in terms of usability at all (maybe worse in readability for people who haven't heard of a 'unit' type).

As for the std::variant use case, using std::monostate is only a matter of convention there. You could use any of the other unit types just the same.

mmaniac• 2 years ago

Why wouldn't you want std::tuple<> to be the same as std::monostate, though? In many languages with a proper unit type such as Haskell and Rust, the zero tuple is the unit type.

ape4• 2 years ago

Good thing they made this instead of expanding the standard library to be more like Java's or Python's. It still only contains the most basic functions, and std::monostate ;)

leecommamichael• 2 years ago

Raymond is a very smart and productive person, and is not maligning C++ at all in this article. It makes me want to reassess my bittersweet perspective on the language.

doctorpangloss• 2 years ago

On the flip side, it shows why so many people are excited about Rust. You can pick up literally any valuable thing off the ground that made the mistake of being built around C++, like CUDA, slap it on Rust, and people will both adopt it and be excited to contribute to it.

furyofantares• 2 years ago

Gerard: But it doesn't do anything!

Hans: No -- it does nothing.

https://scryfall.com/card/wth/154/null-rod

gpderetta7• 2 years ago

No no, that's a void pointer .

nostrademons• 2 years ago

A "monostate" in the design-patterns lingo of 20 years ago was a class with only static member variables, basically where all state is shared state. It was supposed to be alternative to the Singleton pattern where you don't need all those .getInstance() calls and instead can just default-construct an instance, any instance, to get access to the shared state. It fell out of favor because usage was fairly error-prone and surprising to programmers who are not familiar with the pattern. Most people expect that when you create a new instance, you are actually creating new state, but monostate intentionally makes each new instance just a window on the shared global state.

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. But it seems like usage patterns in the article are very different from that, and all the comments here are ignorant of the history of the monostate pattern and befuddled at its intended usage. Maybe it was added to the standard by someone familiar with the design pattern, but they didn't do a good job with education and documentation to explain to everyone else what it was for?

quietbritishjim3• 2 years ago

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

eequah9L• 2 years 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.

layer83• 2 years 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

(originally discussed in http://ftp.math.utah.edu/pub/tex/bib/cppreport.html#White:19...)

kazinator7• 2 years ago

It's poor name. If it has no members, it holds no bits. Therefore it has no state. It's not enough for an object to exist in order to hold state. It must be capable of distinguishing at least between two values, like true or false. If something doesn't hold state, the word state has no business in its name.

This thing is just a counterpart to void that is a class. A better name would be voidclass or something along those lines.

(There is a Monostate pattern, but that involves a class with state: just all the state is static. It's basically like a module with global variables. Completely different thing.)

binary132• 2 years ago

“True” and “False” sound like two states. This is just one. :)

kazinator7• 2 years ago

Yes, exactly like 640K sounds like a power of two, if you're a MS-DOS user.

But in a way, this is right since:

     <no of bits> 
   2                = <no of states>

When the number of bits is 0, 2^0 = 1: 1 state. A state machine with one state is certainly possible.

Problem is we need 2 or more states to do anything useful with state. We can draw an initial state bubble in a state diagram and not add any states; it can even have transitions back to itself.

So maybe monostate is not exactly a misnomer; it's just weird to mention state about something that is not useful for working with state.

JackYoustra3• 2 years ago

There's a fun thing like this in Swift too! `Void` is an empty tuple, and has all of the related constraints (can't conform to protocols, being the most salient one). If you have a type that has to conform to, say, `Equatable` or `Codable` you should instead use `Never?` which you can conform to most protocols via throwing `fatalError` on an extension of `Never` to the protocol.

Anyway, I write basically this on my blog for a more thorough explanation: https://www.jackyoustra.com/blog/non-equatable-void

tymscar• 2 years ago

Lovely blog! If you would accept one suggestion, it would be to make it mobile friendly!

JackYoustra3• 2 years ago

I'm glad to have a mobile reader :) I'll work on making it mobile friendly soon

JackYoustra3• 2 years ago

Should be better now! Let me know if you have further concerns :)

shadowgovt3• 2 years ago

So... Isn't the fact that you can't default-construct that variant without `monostate` working-as-intended?

Not everything can or should be default-constructed or default-constructible. That does complicate initialization sometimes (i.e. there are practical reasons to "suspend" construction until you have all the needed data), but you're not avoiding breaking type safety by adding a `monostate`, you're just giving yourself the "could be null" headache.

vasilipupkin• 2 years ago

this is crazy confusing stuff that should be banned by most sensible internal coding standards.

What's the point of std:monostate? You can't do anything with it

Related Stories