From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-343803-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 3420 invoked by alias); 18 Jun 2013 00:29:04 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 3409 invoked by uid 89); 18 Jun 2013 00:29:04 -0000
X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 18 Jun 2013 00:29:03 +0000
Received: by mail-ee0-f43.google.com with SMTP id l10so2170327eei.2        for <gcc-patches@gcc.gnu.org>; Mon, 17 Jun 2013 17:29:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.105.66 with SMTP id j42mr18926415eeg.126.1371515341106; Mon, 17 Jun 2013 17:29:01 -0700 (PDT)
Received: by 10.15.36.71 with HTTP; Mon, 17 Jun 2013 17:29:00 -0700 (PDT)
In-Reply-To: <51BF617D.3080101@redhat.com>
References: <CANq5Syt5s-NgazOYbT5wtYSRsbZUqcivoer1w4jiucx5qYKMfA@mail.gmail.com>	<CAAiZkiAn9rpPmPKXztUA4rd3CH6w3=tn7jz=oksk65Ypx6RpGg@mail.gmail.com>	<51B0B0ED.5090508@redhat.com>	<CANq5SystWWs=AOAYAHmRjfx17itDrYQj+GtdUr=-XYGLV_4=6g@mail.gmail.com>	<51B0F122.6020301@redhat.com>	<CANq5SysFjY39osn-Xp3HXE-Due7C=D2-VKrhjKdLtpws8rH=mg@mail.gmail.com>	<51B62961.1080409@redhat.com>	<CAAiZkiDY5LZRwgEAmc1VPhbMXJ1ytU_Q2Fj9tSyN1M_T7NMMfw@mail.gmail.com>	<51B8A36C.1080005@redhat.com>	<CANq5SyuWOKxWshSBb8uxtN8d6HMgifJdDcQSrsSwazRjE=v2NQ@mail.gmail.com>	<51BBC613.5040708@redhat.com>	<CANq5SysgoJ0nVdrqLMjFqaWcmz97dB03qbKCs_ZpoBS+OVYzfg@mail.gmail.com>	<51BF617D.3080101@redhat.com>
Date: Tue, 18 Jun 2013 00:29:00 -0000
Message-ID: <CAAiZkiDwyYV5jL-xCdZ3viWDhET+Jv-3ygUDCzKAzfmBLrBzwg@mail.gmail.com>
Subject: Re: [c++-concepts] code review
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Jason Merrill <jason@redhat.com>, Gabriel Dos Reis <gdr@axiomatics.org>
Cc: Andrew Sutton <andrew.n.sutton@gmail.com>, gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
X-SW-Source: 2013-06/txt/msg01015.txt.bz2

On Mon, Jun 17, 2013 at 2:20 PM, Jason Merrill <jason@redhat.com> wrote:

>> I have not thought deeply about constrained friend declarations. What
>> would a friend temploid look like?
>
>
> I was thinking something like
>
> template <class T> struct A {
>   T t;
>  requires Addable<T>()
>   friend A operator+(const A& a1, const A& a2)
>   { return A(a1.t + a2.t); }
>
> };

We agreed about a month ago to have something like this
for member functions.  It makes sense that it applies to friend
too (since it already applies to static member functions.)

One caveat in the design is that the nested requirement can
only add to the outer requirements.

-- Gaby