On 7/9/2017 3:48 AM, Timon Gehr wrote:
> It is indeed incorrect, [...]

Thanks!

On 7/9/2017 3:31 AM, Mr.D wrote:
> scope(exit) assert(0);

It needs to be part of the function signature, not the function implementation.

On 7/9/17 7:07 AM, Nicholas Wilson wrote:
> On Sunday, 9 July 2017 at 10:59:43 UTC, Steven Schveighoffer wrote:
>> On Sunday, 9 July 2017 at 10:51:50 UTC, Daniel N wrote:
>>> On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
>>>> On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
>>>>
>>>>> Has anyone a better idea?
>>>>
>>>> What about
>>>>
>>>> scope(exit) assert(0);
>>>>
>>>> ?
>>>
>>> void func()
>>> out { assert(0); }
>>> body
>>> {
>>> }
>>
>> Yes, this!
>>
> That certainly signals intention, but I still think that an attribute is a whole lot simpler than compiler voodoo like this or the "None" discussed earlier.

This whole proposal is compiler voodoo :)

Unlike a currently undefined attribute, assert(0) in the out contract currently is effective to mean no return. It also guarantees that if there is a return statement somewhere, it still doesn't return.

Also, since the out contract is part of the signature, it will still be present in the case of separate compilation.

The one disadvantage, is that -release removes contracts. So in this particular case, the out contract should remain.

Not sure if it has been mentioned yet, but @disable(return) could work as something that doesn't add any new attributes.

-Steve

On Sunday, 9 July 2017 at 11:26:27 UTC, Steven Schveighoffer wrote:
> On 7/9/17 7:07 AM, Nicholas Wilson wrote:
>> On Sunday, 9 July 2017 at 10:59:43 UTC, Steven Schveighoffer wrote:
>>> On Sunday, 9 July 2017 at 10:51:50 UTC, Daniel N wrote:
>>>> On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
>>>>> On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
>>>>>
>>>>>> Has anyone a better idea?
>>>>>
>>>>> What about
>>>>>
>>>>> scope(exit) assert(0);
>>>>>
>>>>> ?
>>>>
>>>> void func()
>>>> out { assert(0); }
>>>> body
>>>> {
>>>> }
>>>
>>> Yes, this!
>>>
>> That certainly signals intention, but I still think that an attribute is a whole lot simpler than compiler voodoo like this or the "None" discussed earlier.
>
> This whole proposal is compiler voodoo :)
>
> Unlike a currently undefined attribute, assert(0) in the out contract currently is effective to mean no return. It also guarantees that if there is a return statement somewhere, it still doesn't return.
>
> Also, since the out contract is part of the signature, it will still be present in the case of separate compilation.
>
> The one disadvantage, is that -release removes contracts. So in this particular case, the out contract should remain.
>
> Not sure if it has been mentioned yet, but @disable(return) could work as something that doesn't add any new attributes.
>
> -Steve

If the compiler is like a magician, adding an attribute is like conjuring a rabbit, adding the "None" would be like summoning Chthulu.

I like the @disable(return) but I still think a plain attribute is the simplest way to achieve the goals of:
* documentation, is doesn't get much simpler than @noreturn
* optimisation, its already in LDC and GDC, just under a different name
* compatibility between compilers, its as simple as an alias in a version statement per compiler.

On 7/9/17 1:36 AM, Walter Bright wrote:
>>
>> If we wanted to be cute we could use `typeof()` to represent this type as there is no value you can give to typeof such that it returns the bottom type. It also avoids having to come up with some special symbol or name for it.
> 
> That is indeed an interesting idea. Thanks!

We should use typeof(assert(0)) for Bottom. There is precedent - there is no name for typeof(null). -- Andrei

On 7/9/17 7:26 AM, Steven Schveighoffer wrote:
> On 7/9/17 7:07 AM, Nicholas Wilson wrote:
>> On Sunday, 9 July 2017 at 10:59:43 UTC, Steven Schveighoffer wrote:
>>> On Sunday, 9 July 2017 at 10:51:50 UTC, Daniel N wrote:
>>>> On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
>>>>> On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
>>>>>
>>>>>> Has anyone a better idea?
>>>>>
>>>>> What about
>>>>>
>>>>> scope(exit) assert(0);
>>>>>
>>>>> ?
>>>>
>>>> void func()
>>>> out { assert(0); }
>>>> body
>>>> {
>>>> }
>>>
>>> Yes, this!
>>>
>> That certainly signals intention, but I still think that an attribute is a whole lot simpler than compiler voodoo like this or the "None" discussed earlier.
> 
> This whole proposal is compiler voodoo :)
> 
> Unlike a currently undefined attribute, assert(0) in the out contract currently is effective to mean no return. It also guarantees that if there is a return statement somewhere, it still doesn't return.
> 
> Also, since the out contract is part of the signature, it will still be present in the case of separate compilation.
> 
> The one disadvantage, is that -release removes contracts. So in this particular case, the out contract should remain.
> 
> Not sure if it has been mentioned yet, but @disable(return) could work as something that doesn't add any new attributes.

I wonder why there's so much attraction to exotic approaches when encoding "no return" with types has so much established theory and practice with it. -- Andrei

On Sunday, 9 July 2017 at 13:13:28 UTC, Andrei Alexandrescu wrote:
> On 7/9/17 1:36 AM, Walter Bright wrote:
>>>
>>> If we wanted to be cute we could use `typeof()` to represent this type as there is no value you can give to typeof such that it returns the bottom type. It also avoids having to come up with some special symbol or name for it.
>> 
>> That is indeed an interesting idea. Thanks!
>
> We should use typeof(assert(0)) for Bottom. There is precedent - there is no name for typeof(null). -- Andrei

I agree with is approach.
It does not add a magic Type :)

On 7/9/17 9:16 AM, Andrei Alexandrescu wrote:

> I wonder why there's so much attraction to exotic approaches when encoding "no return" with types has so much established theory and practice with it. -- Andrei
> 

Your definition of exotic differs from mine.

I haven't seen another solution other than out { assert(0); } which semantically means "this function cannot return" in the current compiler, and pretty much all historical D compilers, is obvious to the reader that it does so, available in the prototype, and is there and ready for the compiler to optimize with. Literally we have to change nothing in the language or library, only how the optimizer handles it.

Adding specialized attributes, esoteric types, etc, does not have this same level of compatibility. That is why I find this more attractive than any other suggestions so far.

-Steve

On 07/09/2017 10:10 AM, Steven Schveighoffer wrote:
> On 7/9/17 9:16 AM, Andrei Alexandrescu wrote:
> 
>> I wonder why there's so much attraction to exotic approaches when encoding "no return" with types has so much established theory and practice with it. -- Andrei
>>
> 
> Your definition of exotic differs from mine.

Mine is closest to: "strikingly, excitingly, or mysteriously different or unusual" :o) in https://www.merriam-webster.com/dictionary/exotic -- Andrei

On 07/09/2017 10:10 AM, Steven Schveighoffer wrote:
> I haven't seen another solution other than out { assert(0); }

Your own comment takes it to the recycle bin:

> The one disadvantage, is that -release removes contracts. So in this
> particular case, the out contract should remain.

That's already a hack on top of a hack.


Andrei