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 E06F83851A9A for ; Wed, 31 Aug 2022 13:31:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E06F83851A9A 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=1661952718; 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=1jtqBDpsmEIPTGN3mMLavhAZGZ3hVPFnwEAtJEQoteA=; b=XWCW7VQoQwCSZhS/FXPr+ysPufD0WCxo2QGxBkpdr8ZjU2DO0ZWIQHo5pRtsnwUB+i/dMH awNqymg6S3SX45yg7dFpsO7wq+sKY5nSPYvesw7HxV+iRpJffZxTuGY+SQU/Nnn6kpm93a bemDa3MM48C1zN20M/m6EdIRj3iQzk4= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-187-hH5iXzteNpWhv-sGp1XQ2g-1; Wed, 31 Aug 2022 09:31:57 -0400 X-MC-Unique: hH5iXzteNpWhv-sGp1XQ2g-1 Received: by mail-qk1-f197.google.com with SMTP id br15-20020a05620a460f00b006bc58c26501so11659293qkb.0 for ; Wed, 31 Aug 2022 06:31:57 -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; bh=1jtqBDpsmEIPTGN3mMLavhAZGZ3hVPFnwEAtJEQoteA=; b=MFiTvjdQ2DfQXw7Gkb6hRR0PO3zZRZr+rcPqJqyFEF3BRpO7uMMWyZWjxE9p/mafD5 mY4fBvAVGFNglAJQYhNDZleLWey5AP0MsSv+l30edQ2VjlAPXWTZ08rXcnwm2zT5HieW rg14k+eMZLdHmHrIa0Jzt6Z0BE3ZAKEnv7Bo3vuATUxmT6HHRvz/4o8+OGQVGACr0Fzz eEBQQ5zZOtXKKr6nJRH0dBlr3BmXly+UXFsQQHFMMc0lL5ukTAexJRxynaJyucfHq4Qp tQcbOuj96Nx/b6QWPGaVNo95XLflcZHFKTaDiDxiZStGJAn2B1DCdYnF+n9rm+fbarcI c6Ng== X-Gm-Message-State: ACgBeo0rA0o1/dQZCrZgtEpESIMMKXMIH3C+EOb3AuIdNBI7MiCxNGuB 36LFI498fSyn5Lj+2YLCOhv/vuQsmf3tdvvjTjxmw/21aX6f/4ykv4U0f1cJxOCRi/l4L8CkRgu gqzfhMwWBaR76ViRZsAZ0qvW0zPBMzr8= X-Received: by 2002:ac8:5b15:0:b0:343:6789:193a with SMTP id m21-20020ac85b15000000b003436789193amr18557590qtw.647.1661952716765; Wed, 31 Aug 2022 06:31:56 -0700 (PDT) X-Google-Smtp-Source: AA6agR65/f92XZnFpPcbllMy+MwZZKdSyVlLZIdG58X0+vnoPpYZ/GwpGOAQ018IRyFgemCuf+txcqew5e7aL4Ez0S0= X-Received: by 2002:ac8:5b15:0:b0:343:6789:193a with SMTP id m21-20020ac85b15000000b003436789193amr18557553qtw.647.1661952716360; Wed, 31 Aug 2022 06:31:56 -0700 (PDT) MIME-Version: 1.0 References: <20220830171335.54110-1-ppalka@redhat.com> <2fb1f58c-70ee-a271-d508-a7d172c61a1a@idea> In-Reply-To: <2fb1f58c-70ee-a271-d508-a7d172c61a1a@idea> From: Jonathan Wakely Date: Wed, 31 Aug 2022 14:31:45 +0100 Message-ID: Subject: Re: [PATCH 1/2] libstdc++: Implement ranges::adjacent_view from P2321R2 To: Patrick Palka Cc: gcc-patches@gcc.gnu.org, libstdc++@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=-6.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Wed, 31 Aug 2022 at 14:30, Patrick Palka wrote: > > On Wed, 31 Aug 2022, Jonathan Wakely wrote: > > > On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++ > > wrote: > > > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > > > > > + constexpr > > > + _Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base> __last) > > > + { > > > + if constexpr (!bidirectional_range<_Base>) > > > + for (auto& __it : _M_current) > > > + __it = __last; > > > + else > > > + for (ssize_t __i = _Nm-1; __i >= 0; --__i) > > > > ssize_t is defined by POSIX in but isn't in ISO C or > > C++. It looks like MinGW defines it to ... something ... sometimes, > > but I don't think we can rely on it for non-POSIX targets. > > I see. Using ssize_t makes the loop a little cleaner but it's hardly > necessary, so consider it rewritten into: > > for (size_t __i = 0; __i < _Nm; ++__i) > { > _M_current[_Nm - 1 - __i] = __last; > ranges::advance(__last, -1, __first); > } > > > > > > > > + template > > > + struct _Adjacent : __adaptor::_RangeAdaptorClosure > > > + { > > > + template > > > + requires (_Nm == 0) || __detail::__can_adjacent_view<_Nm, _Range> > > > + [[nodiscard]] > > > + constexpr auto > > > + operator()(_Range&& __r) const > > > > Does this attribute actually work here? > > > > I thought we needed to use `operator() [[nodiscard]]` for functions > > with a requires-clause, because otherwise the attribute gives a parse > > error. Maybe I've misremembered the problem, and it just doesn't give > > a -Wunused-result warning. The decl above is setting off my spidey > > sense for some reason though. > > Oops yeah, it looks like this position of [[nodiscard]] works with > standard concepts, but it's a parse error with -fconcepts-ts due to the > different requires-clause grammar. > > Here's v2 which avoids using ssize_t, and puts the [[nodiscard]] after > 'operator()' (_Zip and _ZipTransform have the same issue which I can > fix separately): OK for trunk with those changes, thanks.