From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id E85F3385841A; Fri,  4 Nov 2022 15:04:26 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E85F3385841A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1667574266;
	bh=cYyJjHHlwZ7cKRmLU11qMzkROst6nsE7gTcO337CH/4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=pkZdWu+S3aVy4Aegxv7FAse3QN/Gt8mbPLtYaIIcgXreYqCVhaJteJMkWUELUSJTq
	 JkGBYM+HoeB5epxImDTWEbO0oD5hhAtTYXFWFlXGXfhtIZAdGRsKDEr2ONwuRaY2Jd
	 st+X5hFryFEYx8k/jg688Nwh0qMI3sP9LKgf0hkg=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/107525] propagate_const should not be using SFINAE on
 its conversion operators
Date: Fri, 04 Nov 2022 15:04:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 12.2.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107525-4-7VYbxC7tE5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107525-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107525-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107525

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe D'Angelo from comment #4)
> Sorry, what I meant is, of course there is interest at keeping this code =
to
> compile in pre-C++20 mode, and possibly have the same semantics no matter
> what's the language version used? Or is it acceptable to have such an "API
> break"? (E.g. stuff like `is_convertible_v<propagate_const<Derived *>, Ba=
se
> *>` changes value.)

I think that's fine for TS material.


> More in general, I think these operators are strangely defined. I'm not s=
ure
> why they're not simply defined to be=20
>=20
>   template <typename U> operator U *() requires (std::is_convertible_v<T,=
 U
> *>);
>=20
> mut.mut. for the `const` version.=20

That seems better to me.

> The current definition also allows for pointer arithmetic (only if one us=
es
> a C++20 constraint, otherwise it doesn't work), which is something the
> original paper says it does NOT want to support. And the current definiti=
on
> allows for `delete`ing a propagate_const, which maybe is wanted, but in
> contradiction with the lack of support for pointer arithmetic.
>=20
> I guess I'll need to submit a paper.

Please don't! At least not in the next 9 days. We intend to vote out LFTSv3=
 at
next week's meeting, there will be no more proposals for LFTS considered. A=
nd I
don't want to derail the vote next week by having open proposals arriving at
the last minute.

Feel free to file a library issue though. If propagate_const ever gets prop=
osed
for inclusion in the standard then this should be taken into account.=