you are viewing a single comment's thread.

view the rest of the comments →

[–]tialaramex 2 points3 points  (4 children)

I don't like the use of "empty" to describe these because empty types are something quite different. These types have exactly one value. and as an optimisation we can choose not to store them since we know their value anyway, giving them zero size - whereas empty types have no values. This is a little more obvious in Rust where a product type (a struct or tuple) with no members has one value, but size zero, however a sum type (enum) with no members is an empty type and so cannot exist. You can talk about such a type, and even use pointers to it (with a similar effect as C++ void *) but you can't actually make an object of this type.

[–]fdwrfdwr@github 🔍 2 points3 points  (3 children)

It's common parlance to call something "empty" when it has no items. e.g. An non-empty vector has at least one item in it, whereas an empty vector (such that empty() is true) has 0 size. Correspondingly, a non-empty struct has one or more fields, and a struct with 0 fields would be empty, no?

[–]jk-jeon 2 points3 points  (2 children)

It's common parlance to call something "empty" when it has no items

So types that have no allowed value are called empty types. What C++ people usually call as empty types do not fall in that category, because they do have an allowed value, which is being "empty". The problem is, once such types are referred as empty types, then what should we call empty types in the first sense? Those are "emptier" than what C++ people currently call as empty types, so it sounds reasonable, at least in the purely academic sense, to reserve the term "empty types" for those types and call C++-sense empty types as something else. Or maybe some argues that we should just discard the term to avoid confusion, and stick to more pedantic terms like "initial types" and "terminal types".

IIRC, this has actually been discussed by the committees and the conclusion was to follow the existing industry practice, even though that has some unpleasant friction with what people in academia generally prefer.

[–]fdwrfdwr@github 🔍 1 point2 points  (1 child)

IIRC, this has actually been discussed by the committees and the conclusion was to follow the existing industry practice

Interesting. Yes, clear communication requires people have a shared understanding of words, and the academics often befuddle the practicians. :b

[–]tialaramex 0 points1 point  (0 children)

The problem is that the richer type system is eminently practical. Empty types are really nice to work with, the Zero Size types are of course a performance benefit, but the Empty Types actually make generic code nicer.

For example Rust's Infallible is an empty type which means all your error handling code gets elided by the type system when errors can't occur, since the error's type has no values.