From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 023633851884; Mon, 14 Nov 2022 10:17:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 023633851884 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-pl1-x630.google.com with SMTP id b21so9620756plc.9; Mon, 14 Nov 2022 02:17:34 -0800 (PST) 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=aOMiDrUqv/R2Iw3AHWeCchUueE7K4Q8VRugmso8Xf2Y=; b=ZNJEwAONz5QHHvH2U07va8SOJmeEtyjXAXyMQpDnOpdDY9C+XTWgoMO49F5XFuap50 6EtzXeumoZkVOGqorXzL/Qz1riC3pGviA3nnqxNpSP+quytaI5EfOvgWYV8RJZTBtLQu 2UPaIhO4iLlko6JmQaSSmQN2+o+YAQQsVaoE/cuYsKbja/0j1DjVvKNwyfJ1RkKvOKYG RCb/iw+8SpmhlWnN4QXXKjEGIEXnu28LMJ/9ipy9mgwabWnTo49t931Q/o1/w/O1e4nh T9iz4s9T/7hsAnFSZW0QpoYCkkBha0Dc/oEHUdJU59I7WWWsaXd71nKGWFZyZL6UbXv5 Q3Xg== 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=aOMiDrUqv/R2Iw3AHWeCchUueE7K4Q8VRugmso8Xf2Y=; b=vZVOlH69mezkoPJ+YWweNOqld7JKQ0/EOZK+p7n49hopIBR6+wvUnOMG6kSMM/x14O SShtG9dtvlQJKcvOsJghwpStmkrbTBmhJnMWZiJXUd/D7D0f+0YifZSVBgnZVmUYnGAV 8KeZV3p3OVGAgQYxnyd3+jHKj3cXu1c6qdhQlQ80wLsZmNg7976mhj1AxLX7o7PbhCFp KB9INaqUam+ikBeXNp/IGPH1lafqbdk3tXRmQUy8r17fzJIJoI7Q2hzdz2rrkQPyEqtV zPoJrH2aw44/ZPLWSLxrc8Vhxd8QgCxq+tLujqt2ZAHdrRVjz8ApBfFvFWxASFsF05AW 9uIQ== X-Gm-Message-State: ANoB5pk6InaKJ17ERJLkUs9dN2FX14CwkDGs7ifx/+r6IvBmkJUz8iNi Bi3ZGObCKBeVlUiYLkIQ6khzkweklC2gERa1p24= X-Google-Smtp-Source: AA0mqf5L8TZDGGgbjYZv2BMTkfPDdt5+FmSEDXLofTndxKX3EqMlsUTFEi41qIiaM5NUDCLfR+JJCtRAbNqNFsXPk+A= X-Received: by 2002:a17:902:f10c:b0:17b:9677:1e7c with SMTP id e12-20020a170902f10c00b0017b96771e7cmr12973922plb.93.1668421054000; Mon, 14 Nov 2022 02:17:34 -0800 (PST) MIME-Version: 1.0 References: <20221114045047.362745-1-ppalka@redhat.com> <20221114045047.362745-2-ppalka@redhat.com> In-Reply-To: From: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= Date: Mon, 14 Nov 2022 11:17:22 +0100 Message-ID: Subject: Re: [PATCH 2/3] libstdc++: Implement ranges::iota from P2440R1 To: Jonathan Wakely Cc: Patrick Palka , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_NUMSUBJECT,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: Am Mo., 14. Nov. 2022 um 11:09 Uhr schrieb Jonathan Wakely via Libstdc++ : > > On Mon, 14 Nov 2022 at 04:52, Patrick Palka via Libstdc++ > wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > > libstdc++-v3/ChangeLog: > > > > * include/bits/ranges_algo.h (out_value_result): Define. > > (iota_result): Define. > > (__iota_fn, iota): Define. > > * testsuite/25_algorithms/iota/1.cc: New test. > > --- > > libstdc++-v3/include/bits/ranges_algo.h | 48 +++++++++++++++++++ > > .../testsuite/25_algorithms/iota/1.cc | 29 +++++++++++ > > 2 files changed, 77 insertions(+) > > create mode 100644 libstdc++-v3/testsuite/25_algorithms/iota/1.cc > > > > diff --git a/libstdc++-v3/include/bits/ranges_algo.h b/libstdc++-v3/include/bits/ranges_algo.h > > index da0ca981dc3..f003117c569 100644 > > --- a/libstdc++-v3/include/bits/ranges_algo.h > > +++ b/libstdc++-v3/include/bits/ranges_algo.h > > @@ -3517,6 +3517,54 @@ namespace ranges > > }; > > > > inline constexpr __contains_subrange_fn contains_subrange{}; > > + > > + template > > + struct out_value_result > > + { > > + [[no_unique_address]] _Out out; > > + [[no_unique_address]] _Tp value; > > + > > + template > > + requires convertible_to > > + && convertible_to > > + constexpr > > + operator out_value_result<_Out2, _Tp2>() const & > > + { return {out, value}; } > > + > > + template > > + requires convertible_to<_Out, _Out2> > > + && convertible_to<_Tp, _Tp2> > > + constexpr > > + operator out_value_result<_Out2, _Tp2>() && > > + { return {std::move(out), std::move(value)}; } > > + }; > > + > > + template > > + using iota_result = out_value_result<_Out, _Tp>; > > + > > + struct __iota_fn > > + { > > + template _Sent, weakly_incrementable _Tp> > > + requires indirectly_writable<_Out, const _Tp&> > > + constexpr iota_result<_Out, _Tp> > > + operator()(_Out __first, _Sent __last, _Tp __value) const > > + { > > + while (__first != __last) > > + { > > + *__first = static_cast&>(__value); > > Is this any different to const_cast(__value) ? I think it is. const_cast can potentially mean the removal of volatile, so I would always look with suspicion on const_cast, while static_cast is clearer. Alternatively, as_const could be used, which does add_const_t. - Daniel