From -4859100683777435777 X-Google-Thread: f78e5,1e6093a60facd084 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: Alberto Ganesh Barbati Newsgroups: comp.std.c++ Subject: Re: [Proposal] noreturn_t Date: Sun, 22 Oct 2006 14:19:36 CST Organization: [Infostrada] Lines: 59 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <1161490402.699940.293180@b28g2000cwb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: twister1.libero.it 1161544345 151.44.152.216 (Sun, 22 Oct 2006 21:12:25 MET DST) X-Complaints-To: abuse@libero.it NNTP-Posting-Date: Sun, 22 Oct 2006 21:12:25 MET DST Return-Path: X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu User-Agent: Mozilla Thunderbird 1.5.0.7 (Windows/20060909) X-Scanned: with antispam and antivirus automated system at libero.it X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news2.google.com comp.std.c++:4186 Andrei Polushin ha scritto: > > I propose to add a special type, std::noreturn_t, to indicate that > function does never return. > > > > 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. Even if it's a change that might break backward compatibility, I like it and find it useful. Just three comments: 1) I would not allow implementations to define std::noreturn_t as a typedef to void. In fact I would explicitly disallow such possibility. If we allow it, the code: typedef std::noreturn_t (*doesnt_return)(); void set_handler(doesnt_return f); void bye(); set_handler(bye); might compile on a conforming compiler and not on another conforming compiler. 2) About set_unexpected and set_terminate, I think that changing signatures of existing library function is unacceptable. I would just add overloads. That would rip a little hole in the system, but otherwise it looks like a showstopper to me. 3) I am a bit concerned with the implicit conversion to bool. Although I don't dislike the perl-like syntax, having an implicit conversion would make the entire proposal pointless, because you might then use noreturn_t in a lot more places than we actually want. Even the idiom "implicit conversion to unspecified-bool-type" (as used tr1::shared_ptr, for example) is not good enough, IMHO. I don't see any alternative except to explicitly allow built-in operator || and && (and *only* them, no overloads!) to take as their second operand an expression of type noreturn_t. Just my 2 eurocent, Ganesh --- [ 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 ]