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.133.124]) by sourceware.org (Postfix) with ESMTP id D6E02385042B for ; Wed, 16 Jun 2021 13:53:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D6E02385042B Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-276-aMkxUEBHNSGQslVOgyzTsg-1; Wed, 16 Jun 2021 09:53:28 -0400 X-MC-Unique: aMkxUEBHNSGQslVOgyzTsg-1 Received: by mail-wr1-f70.google.com with SMTP id d5-20020a0560001865b0290119bba6e1c7so1268079wri.20 for ; Wed, 16 Jun 2021 06:53:28 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlxU53ipUDBMQS6iANtKKenSWdVhKesLdaugF2M27WI=; b=UgUys4cd/MDx5KUe6WZPobTlTaqYYlf/a8Ae6rmpa6IbDgR6dCmhbjxn5dcXVwsUnq iVPEG5f40XuMd/6k8tQGvFYVo9A6LfTUSlk1SdGaWBtB1fk5h6o+jOKt2LXEln0IFDJc KcO7lG+3RemEqjg0+QkWvcwaHAVKpDHVVHQQB0SDvn5ockeJNbIn0OhgDx04Ebw/x1Ob 6m0BfAru9/yhuAt+NGwWhDALILQPEEdvuwNQdXjo8jkQ/z80ZgQanpVysEUOTqRRgUId 7g3l8/z4RgWpHg5oxRDTXRYYRRiKJz71df5i02cOHR/stvBJN70ak7qkCsik2aN/zoAf YSrg== X-Gm-Message-State: AOAM532fK+8Nk42vtLtLysaKe+IAFRnlhT6JyzUnNVGstV+nvqGILEXy H9DBcb9Ek/mA2Okr4dlaFoQOO747hEfLmpS/gPAClSitr3sFLHrlbH156WFOR12hObiWCpmsMLz /5XWI6FQj8GIhCl6uizupPnncfvkBeXQ= X-Received: by 2002:a1c:7f96:: with SMTP id a144mr10373165wmd.22.1623851607219; Wed, 16 Jun 2021 06:53:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWdhfyI8+GnQE8UwnYCY9uI5SAh7H1MVfLmP5rLyPRmH5WRjCMjikqeWCXb0tUjYugCy8ZjNuRe74WO1PJwGI= X-Received: by 2002:a1c:7f96:: with SMTP id a144mr10373138wmd.22.1623851606928; Wed, 16 Jun 2021 06:53:26 -0700 (PDT) MIME-Version: 1.0 References: <027d6c9f6afd6b64a279cb698454309c1898f6a1.camel@gnu.org> In-Reply-To: <027d6c9f6afd6b64a279cb698454309c1898f6a1.camel@gnu.org> From: Jonathan Wakely Date: Wed, 16 Jun 2021 14:53:16 +0100 Message-ID: Subject: Re: [PATCH 2/2] libstdc++: Use template form for pretty-printing tuple elements To: psmith@gnu.org Cc: gcc Patches , "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 13:53:32 -0000 On Mon, 14 Jun 2021 at 19:14, Paul Smith via Libstdc++ wrote: > > std::tuple elements are retrieved via std::get<> (template) not > [] (array); have the generated output string match this. Both of your patches seem to be based on the idea that the output is supposed to correspond to how you access the tuple, but that isn't meant to be the case. The fact we show [1] isn't suppose to mean you can access that element as tup[1]. For example, the std::set printer shows: $1 = std::set with 3 elements = {[0] = 1, [1] = 2, [2] = 3} This isn't supposed to imply that you can access the member as s[0]. However, it does use a zero-based index! I think using a zero-based index for tuples makes sense too, although your patch will cause testsuite failures, won't it? The test needs to change too.