From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9388F3858288 for ; Mon, 10 Oct 2022 14:05:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9388F3858288 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665410729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JU/MQMJ7e7Oc9IyLfbEHZgW8vFCULSm7FbEqaopOc7w=; b=fOqQ3vA3z8pKX4qcZ6EeQVhzFB9LUbpCrBhshcTC0QTjvY3BnLzVhWcStmIKwtuUHfWPtJ JkAUH7uLBpbVryEAHMKXW0DVUu+rTn3z2iknxSPeGV0EAG+W2Ky3hsF7/4jr/cfbshLe2e Dxz8cIB9V9pBJZITjFlTy0BjvTYK0v0= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-641-i1yEp3y3OOakxW2Ceq56gA-1; Mon, 10 Oct 2022 10:05:28 -0400 X-MC-Unique: i1yEp3y3OOakxW2Ceq56gA-1 Received: by mail-qv1-f72.google.com with SMTP id 71-20020a0c804d000000b004b2fb260447so4705156qva.10 for ; Mon, 10 Oct 2022 07:05:28 -0700 (PDT) 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=JU/MQMJ7e7Oc9IyLfbEHZgW8vFCULSm7FbEqaopOc7w=; b=1YiT0XOaPO8cdCs4vwNsKMedDOKFW51bfQwR/IfGpYtD8gH8dqUpId4vFFhYI0islK qFCz/yVBpBxhLAtkEGvKA2BAo87wDcH+JSOFjq+3pMSY10NmEsLnITy1/naQITpw58uK 90Z8LXkDIYBrTweyHQ23zeoNmXKkNLbbCsQW/tOfpWSdPIOGPxxfalbOrRI/7BxXG2BF VHh9VUE8nbIl6Fu5mNfq7gCTD9Lv9EWXfG/GZa8ZilsTPYlPssrMANP6Lu+4N/goeA2e It4EliHlaH4eTYmqtdM16f8QYtfusINelvp0t405hMqtvUkwt7HkAkGgQKatl33zUHtd e1WQ== X-Gm-Message-State: ACrzQf1s1GKa5KCgKYjk+Nm7+/wILUqljgUcDxJtNsLsZ94UnFRJoddB Ji4fwZdtt/sqkyJdCXcFq9MdNJ8KNJPVopmOjgsMf4ZWVc1DQ3izFkZTN9Bc7TR1S6njMmqJUzy kfKlzAyOslBR1cHFfCWaEvkZ9zN8y95k= X-Received: by 2002:a05:622a:1189:b0:35b:b923:3667 with SMTP id m9-20020a05622a118900b0035bb9233667mr15137900qtk.165.1665410727748; Mon, 10 Oct 2022 07:05:27 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7W8nreJSjuFl53wZi1UC/FWWXvqGUZTwy6PEt+aeOm9njVO+2tRze9J+QoGO7qVHIdNKb8MpXPTpdlCVk8Fh4= X-Received: by 2002:a05:622a:1189:b0:35b:b923:3667 with SMTP id m9-20020a05622a118900b0035bb9233667mr15137866qtk.165.1665410727465; Mon, 10 Oct 2022 07:05:27 -0700 (PDT) MIME-Version: 1.0 References: <20221010112005.1523979-1-jwakely@redhat.com> <5ff9237f-9298-0964-d61b-58313ae32348@idea> In-Reply-To: From: Jonathan Wakely Date: Mon, 10 Oct 2022 15:05:16 +0100 Message-ID: Subject: Re: [committed] libstdc++: std::make_signed_t should be ill-formed To: Tim Song Cc: Patrick Palka , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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: On Mon, 10 Oct 2022 at 14:50, Tim Song via Libstdc++ wrote: > > On Mon, Oct 10, 2022 at 8:09 AM Patrick Palka via Libstdc++ > 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 but not cv bool. > > > Similarly for std::make_unsigned_t. > > > > > > 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 being > > > incomplete. > > > > IIUC the requires-clause turns what was once a hard error into a SFINAE > > error, so e.g. for > > > > template typename make_signed::type f(int); > > template void f(...); > > int main() { f(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 in a > context that doesn't require its instantiation (e.g., > conditional_t, make_signed, > type_identity>::type). That seems a plausible use case, and > breaking it doesn't seem great to me (conformance aside). Ah yes, that's a problem. We could fix it like this: template struct make_unsigned; template #if __cpp_concepts requires is_integral<_Tp>::value || __is_enum(_Tp) struct make_unsigned<_Tp> #else struct make_unsigned #endif { typedef typename __make_unsigned_selector<_Tp>::__type type; }; But that doesn't really improve the diagnostic much. It's simpler just to revert the addition of the constraints.