public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: mathog <mathog@caltech.edu>
To: <gcc@gcc.gnu.org>
Subject: Re: [bool wrapping] Request for warnings on implicit bool to int conversions
Date: Thu, 29 Mar 2012 17:49:00 -0000	[thread overview]
Message-ID: <225946484a8210239652bd9b276b66a3@saf.bio.caltech.edu> (raw)
In-Reply-To: <4F743777.6040409@westcontrol.com>

On 29-Mar-2012 03:20, David Brown wrote:
> On 29/03/2012 00:52, mathog wrote:

>> A better solution for the aesthetics would have been (it is a bit 
>> late
>> now) to implement the missing unary negation operator:
>>
>> !!b; //T->F, F->T
>>
>
> You can't do that, because "!!" is already a useful operator on
> integers - it turns anything non-zero into 1 while leaving 0 alone,
> and is effectively an "int to bool" conversion operator.

Right, hence the "a bit late now".

(I'm going to use "unary operator" for the rest of this to mean 
operations like ++, an operator that
changes the value of the operand all by itself.  There is some other 
technical term to distinguish that
from a unary "-", for instance, but I have long since forgotten what it 
is.)

I understand we aren't likely to ever see !! as a unary operator 
because of backwards
compatibility issues.  Since unary not is an obvious thing to have 
added to C99 along with
bool, my guess is that they couldn't figure a way to squeeze it in 
without stepping on !!
or something else still needed for backwards compatibility.

This highlights the problem with defining unary operators by repetition 
of single characters,
rather than by using a special symbol to indicate all of the unary 
operators, something like

   i@+ , i@- instead of i++, i--
   +@i , -@i instead if ++i, --i

and so forth, which would have allowed for unary variants of more 
operators. Including those not
considered at the time the language was first constructed. Here:  !@b 
and b@!, but also for
~, for instance.  We are all used to "++" now, but if you think about 
it
"add twice" is not a natural synonym for "increment", whereas 
<var><unary operator symbol><plus> is.

Anyway, this ship sailed a long, long, long time ago.

Regards,

David Mathog
mathog@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

  reply	other threads:[~2012-03-29 17:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-27 22:43 mathog
2012-03-28  1:00 ` Paolo Carlini
2012-03-28  1:19   ` Gabriel Dos Reis
2012-03-28  2:21     ` Russ Allbery
2012-03-28  2:30       ` Gabriel Dos Reis
2012-03-28  2:40         ` Russ Allbery
2012-03-28  2:48           ` Russ Allbery
2012-03-28 19:32       ` [bool wrapping] " Michael Witten
2012-03-28 20:30         ` mathog
2012-03-28 22:21           ` Michael Witten
2012-03-28 22:52             ` mathog
2012-03-29 10:29               ` David Brown
2012-03-29 17:49                 ` mathog [this message]
2012-03-28 22:28           ` Michael Witten
2012-03-28  9:00 ` Franz Sirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=225946484a8210239652bd9b276b66a3@saf.bio.caltech.edu \
    --to=mathog@caltech.edu \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).