From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5989 invoked by alias); 12 Oct 2016 11:40:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4977 invoked by uid 89); 12 Oct 2016 11:40:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=shipped, our, faith X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 11:40:29 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buHtX-0004Mx-U7 for gdb-patches@sourceware.org; Wed, 12 Oct 2016 07:40:28 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buHtX-0004Mj-QK; Wed, 12 Oct 2016 07:40:23 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2861 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buHtV-0000NU-RT; Wed, 12 Oct 2016 07:40:22 -0400 Date: Wed, 12 Oct 2016 11:40:00 -0000 Message-Id: <837f9dbxt1.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org In-reply-to: (message from Pedro Alves on Wed, 12 Oct 2016 12:15:50 +0100) Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr Reply-to: Eli Zaretskii References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <20161011121639.GE3813@adacore.com> <68fc02cb-59bc-012c-d1be-b5ed2076d6a5@redhat.com> <20161011144741.GF3813@adacore.com> <83insydifw.fsf@gnu.org> <83a8eadds7.fsf@gnu.org> <4d49eb8f-5a0c-1e7e-d082-1a224179184f@redhat.com> <831szmd977.fsf@gnu.org> <83vawybol4.fsf@gnu.org> <6ba388f7-1696-42db-ae92-23df79e3ba11@redhat.com> <83oa2qaxe7.fsf@gnu.org> <83fuo1c02j.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00302.txt.bz2 > Cc: brobecker@adacore.com, markus.t.metzger@intel.com, > gdb-patches@sourceware.org > From: Pedro Alves > Date: Wed, 12 Oct 2016 12:15:50 +0100 > > On 10/12/2016 11:51 AM, Eli Zaretskii wrote: > > > Would you please refrain from labeling my (or anyone else's) arguments > > with derogatory labels? Please always assume that anything like that > > is due to some misunderstanding, not to anything else. > > Will do, if you also start assuming good faith on my part. I always do. That's why my arguments weer only about technical aspects and about general human tendencies, not about you personally. > I think worrying about language version requirements is seeing > it backwards from what we should be looking at. IMO, we should > be looking at the distribution sphere (and the distro versions people > are likely to be using/developing on, e.g., latest Ubuntu LTS, past > couple Fedora releases, etc.), and check what are the compiler versions > that are shipped in them, either by default or as optional packages. We could do that, but IME we will not able to collect conclusive data that way. The latest distributions are clearly inappropriate (they always come with the latest compiler versions), and how do you tell how many users out there use which older versions? How do we collect statistics about that? That's why I suggested to use the "how far in the past" criteria. We could decide that N-year old compiler is reasonably old, and always go with the language supported by N-year old compilers. This is an easily testable criterion, and the decision about the value of N doesn't need to be reconsidered too frequently. > And then from that, decide which most up to date language version / > features we can require (if we'd really want to use them). I.e., if in > 5 years, virtually everyone has convenient access to an C++14 compiler, > why not make use of C++14 features if they'd make our lives easier? I question our ability to verify that "virtually everyone" part.