C++Talk.NET

Andrei Polushin · Guest

Hi,

I propose to add a special type, std::noreturn_t, to indicate that
function does never return.

Actually, some compilers have the similar feature, known as either
__declspec(noreturn) or __attribute__ ((noreturn)), but it is used
primarily for optimization purposes and does not affect language.

I suggest using it for strict type checking too, so std::noreturn_t
is not an "attribute", but a type that affects a function signature.

In addition, I suggest the "throw" expression to return "noreturn_t"
instead of "void", see rationale and use case below.

Use cases
---------

Starting from the simplest problem, consider the following code,
which does not compile:

// never returns
void throw_out_of_range(size_type n, size_type m)
{
ostringstream os;
os << "value " << n << " is out of range [0," << m << ")";
throw out_of_range(os.str());
}

// throws if n is out of range [0,size)
reference at(size_type n)
{
if (0 <= n && n < size()) {
return data[n];
}
throw_out_of_range(n, size());
// *error: function "at" should return a value*
}

Yes, we can revert the "if" condition to avoid an error, but why we
need to? Anyway, another example (adapted from boost::lexical_cast):

// never returns
void throw_io_failure()
{
throw ios_base::failure("I/O failure");
}

// throws if I/O failed
char get(const char* prompt) {
char c;
if (!(cout << prompt && cin >> c)) {
throw_io_failure();
}
// *warning: potentially uninitialized variable returned*
return c;
}

Thus we have a spurious warning.

In the following case we will see no warning, where it should be:

int f()
{
abort();

// *no warning about unreachable code*
int n = 22;
return n;
}

More serious case, when the function returns, but nobody expects this:

void hello()
{
cout << "Hello, World!" << endl;
}

set_unexpected(hello);
unexpected();
// execution continues after call to unexpected ?

In the last case, we can know the problem at compile time, imagine
set_unexpected() will accept only handlers that never return:

namespace std
{
typedef noreturn_t (*unexpected_handler)();

unexpected_handler set_unexpected(unexpected_handler f);
}

void hello()
{
cout << "Hello, World!" << endl;
}

std::noreturn_t bye()
{
cout << "Bye, World!" << endl;
// *error: "bye" should never return*
}

set_unexpected(hello); // cannot cast to unexpected_handler
set_unexpected(bye); // ok

Compatibility
-------------

1. Existing C++ implementations that do not check for non-returning
functions, may declare a no-op type:

namespace std
{
typedef void noreturn_t;
}

2. The existing code will fail to compile if it takes the address of
function redeclared with std::noreturn_t return type:

typedef void (*handler)();
void abort_workaround() { abort(); }

handler h = &abort; // error: cannot convert
handler h = &abort_workaround; // ok: workaround

This incompatibility is intentional.

3. Similarly, set_unexpected() etc. will not accept address of
functions that return void, which is also intentional.

4. All control paths of a function that never returns should end
with a call to a function that never returns, or with a throw
statement. This is the direct intent.

Throw expression and noreturn_t
-------------------------------

Throw expression should return std::noreturn_t instead of void, and
the type noreturn_t should be convertible to bool:

namespace std
{
struct noreturn_t {
operator bool() { return false; }
};
}

This allows a Perl-like syntax for checking return value:

cin >> c || throw io_failure("Cannot read from cin");

(Idea inspired by recent posting of Alf P. Steinbach in c.l.c++.m:
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/85b034283152115e/ee9b31479b8c1e0e?#ee9b31479b8c1e0e
)

The name "noreturn_t" is inspired by std::nothrow_t.

Conclusion
----------

Having noreturn_t, we achieve:

- better compile-time control path analysis,
- better runtime error checking syntax,
- easier optimizable code,

Is it useful? I'm waiting for your comments.

--
Andrei Polushin

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Alberto Ganesh Barbati · Guest

Andrei Polushin ha scritto:

Andrei Alexandrescu (See · Guest

Andrei Polushin wrote:

John Nagle · Guest

James Dennett wrote:

Alberto Ganesh Barbati · Guest

Andrei Alexandrescu (See Website For Email) ha scritto:

James Dennett · Guest

Alberto Ganesh Barbati wrote:

Andrei Polushin · Guest

John Nagle wrote:

Andrei Polushin · Guest

Alberto Ganesh Barbati wrote:

Andrei Polushin · Guest

Alberto Ganesh Barbati wrote:

Andrei Polushin · Guest

Andrei Polushin wrote:

Alberto Ganesh Barbati · Guest

Andrei Polushin ha scritto:

Andrei Alexandrescu (See · Guest

Andrei Polushin wrote:

Andrei Polushin · Guest

Andrei Alexandrescu wrote:

Andrei Alexandrescu (See · Guest

Andrei Polushin wrote:

Andrei Polushin · Guest

Andrei Alexandrescu wrote: