From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Tue, 13 Oct 2015 09:52:34 -0400 Message-ID: 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: multipart/alternative; boundary=001a1137f3c0116dac0521fcc2d5 X-Trace: ger.gmane.org 1444745433 32601 80.91.229.3 (13 Oct 2015 14:10:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 14:10:33 +0000 (UTC) Cc: Paul Eggert , Oleh Krehel , Emacs developers To: Mathieu Lirzin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 13 16:10:32 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 1Zm0Hc-0003VJ-7E for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 16:10:28 +0200 Original-Received: from localhost ([::1]:36136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm0Hb-0000Jr-4R for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 10:10:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm00L-0001c7-7h for emacs-devel@gnu.org; Tue, 13 Oct 2015 09:52:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm00K-0005sV-9T for emacs-devel@gnu.org; Tue, 13 Oct 2015 09:52:37 -0400 Original-Received: from mail-pa0-x22e.google.com ([2607:f8b0:400e:c03::22e]:35856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm00K-0005sL-26 for emacs-devel@gnu.org; Tue, 13 Oct 2015 09:52:36 -0400 Original-Received: by pacex6 with SMTP id ex6so22198181pac.3 for ; Tue, 13 Oct 2015 06:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/WChbKGc6SESf0DED/VDxpd5rd7PK7VHfHSw8X/9/XY=; b=J+J/5r93THuyjEkTzGzMyPhOIY21oIPnh+av2kfbFTUDP5HL1uorVIj91gLaLo8Fmo t8b3xWdEDCXaNzDnmhTyjGiWKV4ToNzwI+O1hPJ2A5IalRvwinLAeVr+wF2nYhIo/q6x pXZv3TlyMPhQWbaaXUfKG2D8m2WMKG6t1hmVpPdpkoranDpqiWvb+3Sdef9Z2zHRN+HA Fnz47WYqA52rMgQDTU8VbA8++asY8FprKlh0bdhf1mRr9ow05Kz216HwsEQ9cjpjFHX2 cpXGtqrSYdycnloO50TI3aiceYjfbR4U0xA2NZRnc0pja7qq4R6oxbDNr3I2YcKKauic 4GRg== X-Received: by 10.68.57.175 with SMTP id j15mr40756480pbq.34.1444744354946; Tue, 13 Oct 2015 06:52:34 -0700 (PDT) Original-Received: by 10.66.159.101 with HTTP; Tue, 13 Oct 2015 06:52:34 -0700 (PDT) In-Reply-To: <87si5f0x2s.fsf@openmailbox.org> X-Google-Sender-Auth: Y2zN7ZrQCjrEI8g-O1yo1oP8hNE X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22e 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:191459 Archived-At: --001a1137f3c0116dac0521fcc2d5 Content-Type: text/plain; charset=UTF-8 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). /john --001a1137f3c0116dac0521fcc2d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 13, 2015 at 8:22 AM, Mathieu Lirzin <mthl@openmailbox.org= > wrote:
Oleh Krehel <ohwoeowho@gmail.com> writes:

> For exactly this reason (the confusion over 3 notations, 2 of which ar= e
> the same), I propose that we stick only to "const char *" an= d "char * const",
> and don't use "char const *".

This seems a good idea to me.=C2=A0 It would be nice for this conven= tion to
be documented somewhere.=C2=A0 I think this can be defined in GNU coding standards.=C2=A0 Can you send this suggestion to bugs-standards@gnu.org?

=
Standardizing is= =C2=A0a=C2=A0good thing. Basing the choice purely on subjectiv= e
preference is less so. Many who have loo= ked at the C and C++ grammars
notice that<= /span>

=C2=A0 =C2=A0 const char *

is an historical irregularity th= at has been folded into the grammar as
a=C2=A0special case. Embracing and standardizing = on that special case
detracts from learnin= g=C2=A0a=C2=A0consistent rule and typically leads tomisreading of more complex declarators. The alterna= tive is to leverage
the fact that=C2=A0a=C2=A0const or volatile qualifier always applies to theobject to its left so cv-qualifiers uniformly appe= ar on the right. No
need to remember speci= al case rules or the relative precedence of
various type constructs.=C2=A0 Many C++ well-regarded coding standards
have ado= pted=C2=A0such= =C2=A0a rule (along with moving '*' and '&' left= ward).

/john

--001a1137f3c0116dac0521fcc2d5--