Bottom Type--Type Theory

[H. S. Teoh]

On Thu, Jan 17, 2019 at 12:44:32AM +0000, Nicholas Wilson via Digitalmars-d wrote:
> On Wednesday, 16 January 2019 at 22:32:33 UTC, Walter Bright wrote:
[...]
> > 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.
> 
> Yes that is stupid. Does anyone write it now, given that it is already
> possible with LDC/GDC? No, because D is a pragmatic language, just
> because you can write something non-sensical doesn't mean that anyone
> will, especially when you have to go out of your way to do it.

Actually, there *are* some cases where people might try to write
something like this (not saying it's a good idea, but it's not as crazy
as it might sound at first). To wit:

	// thirdpartylib.d
	class Base {
		int method() { ... }
	}

	// usercode.d
	class Derived : Base {
		override int method() {
			throw new Exception("Not implemented yet");
		}
	}

You cannot write Derived.method as void, because then it wouldn't
override Base.method.


[...]
> > 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.)
> 
> That DIP doesn't make that point at all! If you don't know what you're
> talking about, you should find out _before_ you waste everyones time
> reviewing it!
> 
> This whole DIP needs to be sent back to draft. You need to come up
> with convincing ideas as to why a type is _practically_ more useful
> than an attribute that takes into account the fact that the claimed
> benefits already exist and that the implementation, learning curve and
> other external costs don't outweigh doing it.

Yeah, how did this DIP get so far when it's standing on such shaky
foundations?  Shouldn't somebody of Timon's calibre have been recruited
to iron out the kinks before "final review"? Actually, this should have
been done for the *initial* draft.  This DIP as it stands is far too
crude and incomplete to be this far along in the process.


T

-- 
Tech-savvy: euphemism for nerdy.