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

Timon Gehr timon.gehr at
Tue Jan 18 21:33:38 UTC 2022

On 1/18/22 19:02, H. S. Teoh wrote:
> On Tue, Jan 18, 2022 at 12:55:06AM +0100, Timon Gehr via Digitalmars-d wrote:
>> On 17.01.22 20:39, H. S. Teoh wrote:
>>> Making variables of type noreturn illegal
>> Variables of type `noreturn` should certainly remain legal, perhaps
>> just not default initialization of such variables.
>>> does not preclude taking parameters of type noreturn
>> Sometimes it would, but it should not. E.g., this is fine:
>> noreturn foo(noreturn x){
>>      auto y=x;
>>      return y;
>> }
> Hmm. This again treads that default-initialization / manual
> initialization fine line.

I am not creating any values, I am taking them from the caller. 
Execution already can't reach that variable.

> I can see why such a thing would be useful
> (e.g., you pass a throwing (i.e., noreturn) predicate to a range
> function and expect that it should still compile and run), but having to
> special-case it seems to go against the entire point of having a
> noreturn type.
> ...

I don't understand where you see a special case here. Disallowing 
`noreturn` locals would be the special case.

> Now I'm also lost as to what the "right" behaviour ought to be. :-D
> T

There is no single "right" behaviour due to the prevalence of ad-hoc 
rules in D semantics. I guess if the compiler can show that the code is 
unreachable, then it can default initialize anything, but just allowing 
threading though the non-existent value itself is probably sufficient.

More information about the Digitalmars-d mailing list