From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Tue, 13 Oct 2015 16:30:35 +0200 Message-ID: <878u7696yc.fsf@fencepost.gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <878u78b3hg.fsf@fencepost.gnu.org> <87h9lwyv33.fsf@gmail.com> <561C368F.6010306@cs.ucla.edu> <87oag3xb2i.fsf@gmail.com> <20151013114630.GA4613@acm.fritz.box> <87io6bou1j.fsf@gmail.com> <87si5f0x2s.fsf@openmailbox.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444751910 22057 80.91.229.3 (13 Oct 2015 15:58:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 15:58:30 +0000 (UTC) Cc: Mathieu Lirzin , Emacs developers , Oleh Krehel , Paul Eggert To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 13 17:58:29 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zm1y8-0007oT-AS for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 17:58:28 +0200 Original-Received: from localhost ([::1]:37098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm1y7-00071V-S1 for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 11:58:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm0bB-00047W-UO for emacs-devel@gnu.org; Tue, 13 Oct 2015 10:30:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm0bA-0001vE-Fp for emacs-devel@gnu.org; Tue, 13 Oct 2015 10:30:41 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm0b6-0001tU-Co; Tue, 13 Oct 2015 10:30:36 -0400 Original-Received: from localhost ([127.0.0.1]:49010 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zm0b5-0005Zk-RO; Tue, 13 Oct 2015 10:30:36 -0400 Original-Received: by lola (Postfix, from userid 1000) id 381CADF4F8; Tue, 13 Oct 2015 16:30:35 +0200 (CEST) In-Reply-To: (John Yates's message of "Tue, 13 Oct 2015 09:52:34 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191485 Archived-At: John Yates writes: > On Tue, Oct 13, 2015 at 8:22 AM, Mathieu Lirzin > wrote: > >> Oleh Krehel writes: >> >> > For exactly this reason (the confusion over 3 notations, 2 of which are >> > the same), I propose that we stick only to "const char *" and "char * >> const", >> > and don't use "char const *". >> >> This seems a good idea to me. It would be nice for this convention to >> be documented somewhere. I think this can be defined in GNU coding >> standards. Can you send this suggestion to bugs-standards@gnu.org? >> > > Standardizing is a good thing. Basing the choice purely on subjective > preference is less so. Many who have looked at the C and C++ grammars > notice that > > const char * > > is an historical irregularity that has been folded into the grammar as > a special case. Embracing and standardizing on that special case > detracts from learning a consistent rule and typically leads to > misreading of more complex declarators. The alternative is to leverage > the fact that a const or volatile qualifier always applies to the > object to its left so cv-qualifiers uniformly appear on the right. No > need to remember special case rules or the relative precedence of > various type constructs. Many C++ well-regarded coding standards > have adopted such a rule (along with moving '*' and '&' leftward). I don't get the preoccupation with the order and the talk about "historical irregularity". I can perfectly well write unsigned const int extern x; and that is a well-formed declaration. It doesn't matter in which order the various type declarators appear: you can reorder at will as long as you don't move across * or equivalent. I am not even sure _historically_ (meaning K&R C), storage class specifiers would have had to come before the rest. After all, extern x; was and still is a perfectly valid declaration in C, so a storage class declaration can fill in for a type declaration. -- David Kastrup