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 DFBAF3858D35; Sat,  9 Sep 2023 03:28:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFBAF3858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1694230123;
	bh=DZAu2shHpRxY1ic3TBdv68osj3czIx3nJdLvEkH5UX8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=w/qcu+3mO+f42OWT0xb0FiJpV17ZQo/1U0yNDBOSgr6tH61JZH8sxm7tJ5uhrBJO5
	 zA6hGYAtT8Te2TKMyRfoAwKBjQZlzaKLwQQCMJBGkEq/TjVDIwaT+/pYEz/mZfYpt0
	 FLW5+kfY2M7D2XQuNs1FkoiW0UVe0K6qePAFdTiU=
From: "arthur.j.odwyer at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/111351] constexpr std::string objects permitted to
 escape constant evaluation when SSO
Date: Sat, 09 Sep 2023 03:28:43 +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: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: arthur.j.odwyer at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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-111351-4-pCPGFzBvq2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111351-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111351-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=3D111351

--- Comment #1 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
(Author of the blog post here.)
In contrast to James' view, I think the libstdc++/MSVC behavior is relative=
ly
easy to explain; I think libc++'s `if consteval` approach is baroque and
confusing. [That is, _both_ behaviors are confusing to the newbie and need
expert explanation, but libc++'s choice is confusing even for the experts, =
who
have to maintain its split-brain SSO logic forever because Hyrum's Law. If =
you
have to maintain something forever, you should at least choose to make it
_simple_! As I say in the blog post, in hindsight I think libc++ screwed up
here.]

IMHO it is a feature, not a bug, that I can write these lines:

    constinit std::string s1;
    constinit std::vector<char> v1;

libstdc++ would be within its rights, paper-Standard-wise, to reject both of
these lines; but I don't think libstdc++ _should_ reject either of them.
They're both fine code as far as I'm concerned. I think libc++ is the
user-hostile/broken implementation here, not libstdc++.

Anyone who thinks libstdc++ ought to reject `s1` above should at least be
forced to explain what libstdc++ ought to do about `v1`. From the
user-programmer's POV, there's no difference between a default-initialized
string and a default-initialized vector. Users don't care about these SSO
details; they just want the code to work. That's what libstdc++ currently d=
oes.
Good, IMO.=