From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely@redhat.com>
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 D05523851C1C
 for <libstdc++@gcc.gnu.org>; Wed,  3 Mar 2021 14:30:33 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D05523851C1C
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-84-ZpS2fZUCOBu17UiBebGVZQ-1; Wed, 03 Mar 2021 09:30:29 -0500
X-MC-Unique: ZpS2fZUCOBu17UiBebGVZQ-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
 [10.5.11.12])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8E71880198D;
 Wed,  3 Mar 2021 14:30:28 +0000 (UTC)
Received: from localhost (unknown [10.33.37.30])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 7BD6D60C6A;
 Wed,  3 Mar 2021 14:30:21 +0000 (UTC)
Date: Wed, 3 Mar 2021 14:30:20 +0000
From: Jonathan Wakely <jwakely@redhat.com>
To: Ville Voutilainen <ville.voutilainen@gmail.com>
Cc: Thiago Macieira <thiago.macieira@intel.com>,
 Thomas Rodgers <trodgers@redhat.com>, libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: C++2a synchronisation inefficient in GCC 11
Message-ID: <20210303143020.GR3008@redhat.com>
References: <1968544.UC5HiB4uFJ@tjmaciei-mobl1>
 <1642718.4M2VOOmbIH@tjmaciei-mobl1>
 <CAFk2RUYT-6LNp4ftuR_N43Udzr=6J2miibB4zt+234JtGSh95g@mail.gmail.com>
 <1997681.6Qe2hjFSQd@tjmaciei-mobl1>
 <CAFk2RUa8iCZYQ-b8Pv9yuBfOSikt08rMXcA1MvRQjtX=GO2UcA@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAFk2RUa8iCZYQ-b8Pv9yuBfOSikt08rMXcA1MvRQjtX=GO2UcA@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
X-Spam-Status: No, score=-7.9 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, 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 <libstdc++.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/libstdc++/>
List-Post: <mailto:libstdc++@gcc.gnu.org>
List-Help: <mailto:libstdc++-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 14:30:34 -0000

On 27/02/21 02:44 +0200, Ville Voutilainen via Libstdc++ wrote:
>On Sat, 27 Feb 2021 at 02:36, Thiago Macieira <thiago.macieira@intel.com> wrote:
>> Those goals seem incompatible. If the feature is experimental and not to be
>> used in production, then we don't want users to adopt the facilities early. We
>> want them to wait until we declare that it's no longer experimental.
>
>Well, we want *bold* users to adopt new facilities early. Not all users.

Yes, exactly. They could still do that if some additional option/macro
was needed to get to those new facilities though.

My concern is that if we add a new "I know what I'm doing" option,
everybody defines it (because that's what blog posts and youtube
videos and conference talks tell them to do, because that gives them
the new shiny things) and then it just becomes a default.

Maybe Qt wouldn't define it, but plenty would.