From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by sourceware.org (Postfix) with ESMTPS id 706403858D39 for ; Sat, 2 Sep 2023 08:43:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 706403858D39 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com Date: Sat, 02 Sep 2023 08:43:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1693644222; x=1693903422; bh=Gps1IAqE42FL37eeK+zQS6e8wQeyMeHF6DntWLmzG+w=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hdIPhNI7Ci/sarWOcs2OhTuqKOmvEKnhODcCUNOcVu7Bqp8/yK3+E1X8KLm0ZZ8TF htnv2jEW91ZpLO4QTM7C+cdzo35VqVZq9TfHhhrPj6vy3jmEl2P/WOCrmEYqq+VPhy JrYVtKd3zl5JKkKQBlYv+QesYSRG5wF/lwKDugspSsg5GrQS+WljiaI5G5gE/upnmO LNOv6wXa+ZcwXPcAK1Wf+u3TORN4hRPvDgkWyYh1qi+CrBGmDv0IUFdc2hruilkmJ2 zH3PQi+AJ99fH5OZyCp67Zm7UredALJOHvrAlGhcusenkO6DPnk/BXw5s38FhJkPY4 2Lec5FjwuwBzQ== To: Jakub Jelinek From: waffl3x Cc: Jason Merrill , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: References: Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: Hey Jakub, thanks for the response and criticism, as soon as I am back at a computer I will address the issues you raised, I have a few questions though. I apologize in advanced for any errors in formatting this message, I'm writing it from a hotel room on a phone so errors are inevitable, but I'll try my best. >More importantly, should describe >what changed and not why I was under the impression that if someone wants to see the what, they can just check the diff. I don't understand what should be written if I'm just to say what, wouldn't I just be repeating what is already said in the code itself? >I think usually we don't >differentiate >in testcase names whether Yeah, for sure, but I felt like there is value in differentiating them and that it would be harmless to do so. If you feel like it's more important that convention is followed here I won't object, but I think this should be considered. >Isn't explicit-object-param too long >though? >explicit-this or deducing-this might >be shorter... I agree, but I felt like I should stick to the wording of the standard for it, but I don't feel strongly about that justification, so I wouldn't object to changing it. Truthfully I flip flopped many times around the names, I'll defer to whatever is decided by the maintainers on that without complaint. >> +} >> \ No newline at end of file >Please avoid these Yeah, I noticed it last minute and wasn't sure how big a deal it was. I will make sure to fix it along with everything else you noted. >Usually runtime tests don't try to >print something Yeah, I didn't like printing, but I'm not sure I like aborting either. I value granularity in testing, if one part of the test passes but another fails, you would want to know that. If you abort before the second you lose that granularity. Once again, I'll defer to the maintainers for this, but I think my points are valid here. >This raises an important question whether we as an extension >should support deducing this even in older standards or not. >I admit I haven't studied the paper enough to figure that out. I'm glad you think so, I fully agree. I had planned to raise that once the initial patch made it in. I don't believe there is anything in the paper in particular that breaks previous standards. I can imagine there being problems if older projects tried to convert everything to use it as there are alignment differences (at least in the current patch version) between explicit object member functions and implicit object member functions. This is mostly a side effect of treating them as static functions most of the time, but I wasn't sure what would be ideal, nor how to change it. I decided that the difference was likely mainly due to virtual functions (if you know more about this, please be sure to correct me), and as virtual is not (currently) allowed, I just left it as it is. In short, I agree, and furthermore I think the syntax should be allowed with virtual just so style can be maintained. That would have greater implications than what you mentioned though and would need some extra hacks to make work, instead of just allowing what should -just- work. Thanks again for the input, I will get on it asap. Unfortunately that will be in a while, but I am determined to get this feature into GCC14 so one way or another I will make it happen. -Alex