From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <t.canens.cpp@gmail.com>
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b])
	by sourceware.org (Postfix) with ESMTPS id BB4763858284;
	Mon, 10 Oct 2022 13:50:19 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB4763858284
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-3321c2a8d4cso101089957b3.5;
        Mon, 10 Oct 2022 06:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=tKV0Z45rkwLtTJz4Dlm6xRjv3KJjekQJ7roVRn4Rf70=;
        b=X3lL5XxSi1a+F61sRpSt3nXaTTHltMvU3yfJQWN2U/AgmviuZEcG8xIq+BLieAatL4
         +k3nvWKFEnds2p0xz92mqN1fasxKOzQUb1TJWiHpbzGPzfj57ExeM+n0TipjdXdsrihf
         DUmr0esb6A+LmoRnh5oYZeVCpRZQt2xhWRLsc/MnOkWRZUf4EP5e3jAjGznCcHRTDhoR
         +7i6IqyfGD2yfSthQwjugRwMGKI3uI/lRGeJS1uLokDR9YqJDYd4DyzQhjTitm59cwIC
         P1WTWNF50FJr720Mj6vGVv0olVQkaLx4Tx8yHDxjxPnjwd/3ms9H20yEQwscw2Ku7rSf
         CNUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=tKV0Z45rkwLtTJz4Dlm6xRjv3KJjekQJ7roVRn4Rf70=;
        b=Js9L4PxRoBAxFoZ1e7w466M87RCDcy5sxvgX48y1b4CxrIdzXVE6VP39DOtpwcXTSJ
         JzgSOaEhq3MskOwzjkDCLSh8DcBoXWMvUwptUeA4l9qZCSzoIix3baR4X/S3bVrHw6Ho
         62nL2uxhy9CAB/y9AtIUT8ZsogtPCrV5xAkL43CNzsFdHLMG4pXcEHiIwMhSDc+cDXop
         wBnXAAGPNjzlGKl96qWcfVaLGYQN2jRR2efy9H9ln0fQaKvvpc6KVVA8eFKDhRiEOuVq
         ru4w6b4ygv70b5aiInJFIONQQPDOrD5gIxAXKzwggLWzGaKz08Ie47+LWB5uz9TcAxY1
         7qSQ==
X-Gm-Message-State: ACrzQf3jmh/j6cds1+z607rlOvci+iiMewM81C2cR4SyZsmaiyy6obTp
	Yi00x6v9Dj1V3wK1NWGt07gt7JV+M5WIR5n9Opw=
X-Google-Smtp-Source: AMsMyM7dn9jTvR6fTgvnv3aeFG92smNxB4L6JF9zd24TlFJh5RVGL3GaDU7X80npfHA1yfNa9kMImfssZaRIAe8m80w=
X-Received: by 2002:a81:a087:0:b0:357:3a80:1fca with SMTP id
 x129-20020a81a087000000b003573a801fcamr16802531ywg.481.1665409819035; Mon, 10
 Oct 2022 06:50:19 -0700 (PDT)
MIME-Version: 1.0
References: <20221010112005.1523979-1-jwakely@redhat.com> <5ff9237f-9298-0964-d61b-58313ae32348@idea>
In-Reply-To: <5ff9237f-9298-0964-d61b-58313ae32348@idea>
From: Tim Song <t.canens.cpp@gmail.com>
Date: Mon, 10 Oct 2022 08:49:43 -0500
Message-ID: <CAPQZVxtXObqvQj1M+Z5J_kQM_6N9ENbumCp98X-eLuyxgQQVNg@mail.gmail.com>
Subject: Re: [committed] libstdc++: std::make_signed_t<cv bool> should be ill-formed
To: Patrick Palka <ppalka@redhat.com>
Cc: Jonathan Wakely <jwakely@redhat.com>, libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libstdc++.gcc.gnu.org>

On Mon, Oct 10, 2022 at 8:09 AM Patrick Palka via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On Mon, 10 Oct 2022, Jonathan Wakely via Libstdc++ wrote:
>
> > Tested powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Currently we only reject std::make_signed_t<bool> but not cv bool.
> > Similarly for std::make_unsigned_t<cv bool>.
> >
> > As well as making those ill-formed, this adds a requires-clause to the
> > make_signed and make_unsigned primary templates. This makes
> > non-integral, non-enum cases fail immediately with a clear error, rather
> > than giving an error about __make_signed_selector<T, false, false> being
> > incomplete.
>
> IIUC the requires-clause turns what was once a hard error into a SFINAE
> error, so e.g. for
>
>   template<class T> typename make_signed<T>::type f(int);
>   template<class T> void f(...);
>   int main() { f<void>(0); }
>
> the call to f would previously be rejected due to an error outside the
> immediate context about incomplete __make_signed_selector, and now with
> the requires-clause resolves to the second overload.  I wonder if this
> new behavior is conforming -- the examples in [structure.specifications]
> of how to implement 'Mandates' suggest that a failed 'Mandates' should
> yield a hard error?

I'm also concerned about the inability to name make_signed<X> in a
context that doesn't require its instantiation (e.g.,
conditional_t<is_integral_v<T>, make_signed<T>,
type_identity<T>>::type). That seems a plausible use case, and
breaking it doesn't seem great to me (conformance aside).