From -1912884659688547186 X-Google-Thread: f78e5,1e6093a60facd084 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-lei1.dfn.de!news-fra1.dfn.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!skynet.be!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: SeeWebsiteForEmail@erdani.org ("Andrei Alexandrescu (See Website For Email)") Newsgroups: comp.std.c++ Subject: Re: [Proposal] noreturn_t Date: Sun, 29 Oct 2006 04:22:50 GMT Organization: Computer Science & Engineering, U of Washington, Seattle Lines: 58 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <4544215C.4020102@erdani.org> References: <1161490402.699940.293180@b28g2000cwb.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1162095782 7707 158.152.254.254 (29 Oct 2006 04:23:02 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 29 Oct 2006 04:23:02 +0000 (UTC) X-Nntp-Posting-Host: tisbe.cs.washington.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666 X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.csse.unimelb.edu.au id k9T4MwRD026906 X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.csse.unimelb.edu.au (8.13.6+Sun/8.13.6/Submit) id k9T4MoS7026846; Sun, 29 Oct 2006 15:22:50 +1100 (EST) X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news2.google.com comp.std.c++:4236 Tommi H=F6yn=E4l=E4nmaa wrote: > Andrei Polushin kirjoitti: >> 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. >=20 > This is a question about the execution flow and not about the result=20 > type of a function. There would be no values whose type is noreturn_t. > So "noreturn" should be an attribute of a function like the throw=20 > specifications. The point of the idea was different. Yes, values of that type cannot=20 exist, but the properties of the static type control the expressiveness=20 of the idioms in which the type could take part. And precisely because=20 values of that "none" type can never exist, there is considerable static=20 freedom with regard to the static properties of that type, which confers=20 it remarkable expressiveness. > "noreturn" and other attributes should be part of the type of the=20 > function (i.e. function pointer type), not the type of the result value. >=20 > BTW, there should also be attribute "pure" to indicate that a function=20 > has no side effects. A pure function would not be allowed to call any=20 > non-pure functions or to change global variables. GCC implements "pure"= =20 > and "const" attributes for pure functions. Pure is a good comparison point with no-return as it is purely (no pun=20 intended) related to a flow property of the function, with (to the best=20 of my imagination) is not related to its type. > A function with the pure attribute would be compatible with the=20 > corresponding function type with or without the pure attribute. A=20 > function without the pure attribute would not be compatible with > the corresponding function type with the pure attribute. >=20 > There could be another attribute "mustreturn" to indicate that a=20 > function has to return. "mustreturn" and "noreturn" would be mutually=20 > exclusive. I guess mustreturn is simply a static incarnation of the nothrow idea.=20 Things get tricky when we start thinking of mustreturn as a guarantee=20 that the function doesn't enter infinite loops - it wouldn't generally=20 be quite possible to demonstrate that a function violates that=20 assumption :o). Andrei --- [ 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 ]