On 07/08/2017 01:14 PM, Jack Stouffer wrote:
> On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:
>> Why should this be an attribute rather than a pragma?
> 
> I agree. There's no reason I can think of as to why the no-return should be part of the ABI.

If present in the signature of the function you can figure that the function won't return by introspection. -- Andrei

On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu wrote:
>
> What is the signature of a function that logs something to a file and ends in assert(0)?
>

I do get your point.
However I still doubt that this is worth a the additional language complexity.

Usually the clue would be in the name.
sth. like
void logAndDie(string lastWords) { ... }

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote:
> On 7/8/17 6:15 AM, Walter Bright wrote:
>> Has anyone a better idea? Does anyone want to write a DIP for this?
>
> An attribute is fine. A more PL-minded possibility is to return a specific type:
>
> struct None
> {
>     @disable this();
>     @disable this(this);
>     @disable @property None init();
> }
>
> None ThisFunctionExits();
>
> The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a function, and therefore decrees the function will never return.
>
>
> Andrei

I wonder if some lessons from Haskell's "bottom" type would be relevant here.

On 7/8/17 2:26 PM, John Colvin wrote:
> I wonder if some lessons from Haskell's "bottom" type would be relevant here.

Affirmative. The nice touch of bottom (heh) is that it's convertible to anything, so you can use it in complex expressions as a wildcard. -- Andrei

On 7/8/17 1:30 PM, Stefan Koch wrote:
> On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu wrote:
>>
>> What is the signature of a function that logs something to a file and ends in assert(0)?
>>
> 
> I do get your point.
> However I still doubt that this is worth a the additional language complexity.

Yah, there's marginal utility only - improves code generation and makes a few awkward workarounds unnecessary. Yet many other languages and implementations have it, so apparently the utility is justifiable.

> Usually the clue would be in the name.
> sth. like
> void logAndDie(string lastWords) { ... }

Problem here being this code is opaque to compile-time analysis and to introspection. Unless, that is, the compiler understands the name (smell) or the introspection does heuristics on name - e.g. everything that ends in "andDie" does not return (smell). -- Andrei

On 7/8/2017 3:52 AM, Nicholas Wilson wrote:
> consider that GDC and LDC already both have that attribute courtesy of their backends (@attribute("noreturn") and @llvmAttr("noreturn") respectively).

One could argue that since "noreturn" changes the interface of a function, it should also change its signature (i.e. name mangling). I don't believe this is currently the case with any C++ compiler, or with LDC/GDC.

And frankly I'm sure it's annoying to users to use that attribute portably between GDC/LDC. The concept of noreturn should be part of the language, not a compiler implementation.

On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote:
> None ThisFunctionExits();
> 
> The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a function, and therefore decrees the function will never return.

That is a scathingly brilliant idea. It has another nice effect - the compiler doesn't have to diagnose:

   @noreturn int foo();

as an error!

Me like.

On 7/8/2017 10:14 AM, Jack Stouffer wrote:
> On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:
>> Why should this be an attribute rather than a pragma?
> 
> I agree. There's no reason I can think of as to why the no-return should be part of the ABI.

Separate compilation. I.e. if one changes the implementation of a function such that it now returns, it will break any compiled code that relied on it being noreturn.

This is why, for example, nothrow is part of the signature.

On Sat, Jul 08, 2017 at 01:09:35PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote:
> > None ThisFunctionExits();
> > 
> > The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a function, and therefore decrees the function will never return.
> 
> That is a scathingly brilliant idea. It has another nice effect - the compiler doesn't have to diagnose:
> 
>    @noreturn int foo();
> 
> as an error!
[...]

Hmmm. Just to clarify, what exactly does @noreturn include? If I have a function that calls exit(), that's @noreturn? What about a function that always throws? Or a function that calls exec()? A function that always ends in assert(0)? A function that context-switches to a different thread / fibre and terminates this one?

Personally, I'm for this. It is useful for functions that constructs then throws an exception, for example. It would be nice to be able to call such a function from another function that returns non-void without having to insert assert(0) into the latter to avoid the compiler complaining that you failed to return a value.

As for Andrei's idea, it's pretty clever but we would need to standardize the None type, otherwise we risk hard-to-read code when everyone rolls their own None type with different names. An attribute has the advantage that it will be universally understood.


T

-- 
It only takes one twig to burn down a forest.

On Sat, Jul 08, 2017 at 01:20:03PM -0700, H. S. Teoh via Digitalmars-d wrote: [...]
> Personally, I'm for this. It is useful for functions that constructs then throws an exception, for example. It would be nice to be able to call such a function from another function that returns non-void without having to insert assert(0) into the latter to avoid the compiler complaining that you failed to return a value.
> 
> As for Andrei's idea, it's pretty clever but we would need to standardize the None type, otherwise we risk hard-to-read code when everyone rolls their own None type with different names. An attribute has the advantage that it will be universally understood.
[...]

Also, a @noreturn attribute would allow overriding a non-void class method with a @noreturn one (e.g. the derived class is a sentinel object that forces an exception / termination upon calling that method), whereas you can't do that with a None return type because the signature would not match the base class's.


T

-- 
"Hi." "'Lo."