From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76450 invoked by alias); 1 Jul 2017 21:42:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 76437 invoked by uid 89); 1 Jul 2017 21:42:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=cam X-HELO: mail-io0-f181.google.com Received: from mail-io0-f181.google.com (HELO mail-io0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Jul 2017 21:42:27 +0000 Received: by mail-io0-f181.google.com with SMTP id h64so39352126iod.0 for ; Sat, 01 Jul 2017 14:42:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KHCNOUkGAp4fTFliC0cIeQTpLKLeummXBFrFKE4GWSY=; b=dHecMZBnfOA/jM5MctuSeggoU+RguBE5RJWU8+eSXrUyjd9UgHl3rmXif7TPTh6JVQ Gg/ATxCPOTt6FuhmQN3IkN96eeEL84sYXFZH/W0seEcG7WKkJ1rR3wKoPAyczpkpSNwt p1KNwQ2DhL4aoDrItKWarbDXVBixFhKaWsoDnQkM3JW4T+pm3x9ZI5SzzQf0S68NWrud j9BAy6hoCD9rha/rF2ADd2pZHm5/TE/0SmOehqMMmO/nksZ406NUgKBMAsYydYXjyBSs W32fV9VsNTM/lg5GMBCXL+Rudp0ETi7xBKBT5sxLd4wwwLQPAwdqkCInuM7+8UjtWej3 uQ/Q== X-Gm-Message-State: AKS2vOyIJTGPrH5J5E9/l4gUlgK1nqfrjX27/VB4pTLTfcbLbW1qDKgL 4EXjVuk0TF8BOGi9jPBh4WZXrXLam/mn X-Received: by 10.107.15.80 with SMTP id x77mr11937047ioi.2.1498945345888; Sat, 01 Jul 2017 14:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.105 with HTTP; Sat, 1 Jul 2017 14:42:05 -0700 (PDT) In-Reply-To: <76d44f1b-0c31-094b-1f2a-d8a8ecc9e32e@gmail.com> References: <620e2b9e-a77e-167d-52e3-0b34efa688a5@gmail.com> <76d44f1b-0c31-094b-1f2a-d8a8ecc9e32e@gmail.com> From: Jason Merrill Date: Sat, 01 Jul 2017 21:42:00 -0000 Message-ID: Subject: Re: [PATCH] document cp_operator_id and cp_assignment_operator_id To: Martin Sebor Cc: Gcc Patch List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00024.txt.bz2 OK. On Thu, Jun 15, 2017 at 6:57 PM, Martin Sebor wrote: > On 06/15/2017 03:24 PM, Jason Merrill wrote: >> >> On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor wrote: >>> >>> Attached is a documentation-only change to add comments explaining >>> the C++ cp_operator_id and cp_assignment_operator_id macros. >> >> >> Hmm, I'd say that these macros return the identifier used internally >> to represent "operator OP" and "operator OP=", respectively. Looking >> up overloads is one thing you can do with that name, but the same is >> true of all identifiers, do we need to mention it specifically? > > > I tried to describe the use case that I needed but that wasn't > obvious to me from the examples I cam across. > > If these cp_foo_id() helpers and the other identifier macros were > defined and documented in one place there could be a few examples > at the top of the section listing them showing some of the less > obvious use cases. As it is, cp_operator_id() and > cp_assignment_operator_id() are defined in one place (and using > the cp_foobar_id() naming convention), while the {ctor,dtor}_ > identifier macros in another (and using a different convention). > Perhaps there's a good reason for it but knowing as little as > I do I find it confusing because I used both to do the same > thing: iterate over the overloads of the special functions. > > With that in mind, attached is an update that tries to clarify > things without mentioning the example in the comments for (just) > the operator _id macros. > > If you have a better suggestion I'll be happy to take it. > > Martin