Bottom Type--Type Theory

Walter Bright newshound2 at digitalmars.com
Wed Jan 16 22:32:33 UTC 2019


On 1/16/2019 3:40 AM, Olivier FAURE wrote:
> What is your answer to the rebuttal, common in both this thread and the previous 
> thread, that a bottom type has no practical use justifying the complexity (and 
> probable corner cases) it would add to the type system?

That indeed is the correct question.

The thing is, I know little about formal type theory. As far as I can tell, 
nobody in this community does either, aside from Timon Gehr.

There are notions in mathematics and programming that seem like nonsense, but 
exist as important boundary conditions:

* zero
* infinity
* black hole objects
* white hole objects
* identity functions
* top type (represents every value, like D's "Object" root type)
* bottom type (represents no value)

Civilization had arithmetic long before zero was discovered. Today, we can't 
imagine doing math without 0. Infinity came along later, and its usefulness can 
be seen as an indispensable foundation of calculus.

C++ muddled along for decades with an identity function being impossible to 
write. Although an identity function seems pointless, it went unrecognized for a 
long time that this was causing all sorts of problems with templates.

Back to the bottom type. C's ability to manipulate types is so primitive nobody 
misses type calculus. But D can do type calculus, and I worry that the lack of a 
bottom type, far from creating corner cases, causes corner cases and awkward 
problems analogous to what the lack of an identity function causes.

The trouble is, I don't know enough about type theory to know if this is the 
case or not. I only know analogies to problems other systems have when the 
boundary cases are not expressible.

An example of an awkward corner case caused by lack of a bottom type:

    @noreturn int betty();

How can it return an int yet not return? It makes no sense. And if one was doing 
type calculus on the return value of betty(), it would show up as 'int' and 
botch everything up. It'd be like substituting '5' in calculations that need a 
'0', but have no notion of '0'.

The trouble with 'void' as a bottom type is it is only half done. For example, 
'void' functions are procedures, and certainly do return. A void* is certainly a 
pointer to something, not nothing. 'void' is the one with awkward corner cases, 
it's just we're so used to them we don't see them, like few C++ people 
recognized the identity function problem.

My trouble explaining the immediate value of a bottom type stems from my poor 
knowledge of type theory. Other languages aren't necessarily good role models 
here, as few language designers seem to know much about type calculus, either. I 
was hoping that someone who does understand it would help out!

(I.e. it's not just about functions that don't return. That's just an obvious 
benefit.)


More information about the Digitalmars-d mailing list