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

[Timon Gehr]

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.