bottom type as parameter or local variable, does that make sense?

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 17 19:39:49 UTC 2022


On Mon, Jan 17, 2022 at 07:23:05PM +0000, Paul Backus via Digitalmars-d wrote:
> On Monday, 17 January 2022 at 18:40:55 UTC, H. S. Teoh wrote:
> > On Mon, Jan 17, 2022 at 06:11:09PM +0000, Paul Backus via Digitalmars-d
> > wrote:
> > > 
> > > Both the rewrite I describe and the behavior you propose are
> > > special cases.  The non-special-case behavior is "compile-time
> > > error."
> > 
> > OK, so it should be a compile-time error, then.
> 
> ...and then you need special cases in generic code to deal with
> noreturn. So the question is, what's the cost/benefit of adding a
> "pragmatic" special case to the language here?

What kind of special cases, specifically?  Making variables of type
noreturn illegal does not preclude taking parameters of type noreturn.
Most current generic code does tests of the form:

	template someTpl(T)
	if (is(typeof((T t) {
			... // tests on t here
		})))
	{ ... }

This wouldn't be affected by the fact that T may be noreturn. If the
generic function actually needs to instantiate a variable of type T,
then it *should* be a compile error when T is noreturn anyway (because
it can't possibly do anything meaningful with such a variable, and the
fact that instantiation wasn't prevented means there's a logic error
somewhere).


> In any case, the DIP has already gone through the full review process
> and been accepted, so whether we agree with it or not, the decision
> has already been made.

Sine when does that mean things are set in stone?


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy


More information about the Digitalmars-d mailing list