From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 50F49138CAE for ; Sat, 2 May 2015 22:19:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF90AE0880; Sat, 2 May 2015 22:18:59 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EAC3FE07F2 for ; Sat, 2 May 2015 22:18:58 +0000 (UTC) Received: by pabtp1 with SMTP id tp1so125398577pab.2 for ; Sat, 02 May 2015 15:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=52t/AEeorX2fORx9sgFx8WKhiy9Pqps7winkdlSiR+4=; b=PQp/sie3qWfmpR3FoI2H3NlxIQ+HgutYJMFEOp9tacwY4GDyZSJX81ElTm7Ajq4v6G +hXwKonpqpG84DhTuWOkwcxJGjii9sKpSscYgD0hZfE6jrYcSdiF9zYZTo15Uc8ZGM10 ArQe9uEjzxOpjXmpwWIJ6uXZU6LtPIKgCUDQ6RjCkdbdMBE8I3vH9EL95fo50atCnvR0 +kmxBQGI1o1p+6gs0zKfczDH1nyHssTypUaBB8lL1Pkf+kwNtrWeChmrfjaz8bZr5aIM Fs142jzvsEYgbWLqCVsk2SU7ZJEbWQN8YHDH8pABzo3z2Gir04wd71LU1LDHTShKlH/R +Bmg== X-Received: by 10.70.38.195 with SMTP id i3mr29959011pdk.82.1430605137931; Sat, 02 May 2015 15:18:57 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.70.29.131 with HTTP; Sat, 2 May 2015 15:18:37 -0700 (PDT) In-Reply-To: References: <20150424194217.0176adc0@googlemail.com> <553A91F6.7080505@gentoo.org> <553BA02E.7000805@gentoo.org> <20150425152317.20001.qmail@stuge.se> <553FE89B.2000903@gentoo.org> <5540C01C.7090202@gentoo.org> From: Georg Rudoy <0xd34df00d@gmail.com> Date: Sun, 3 May 2015 01:18:37 +0300 Message-ID: Subject: Re: [gentoo-dev] Re: RFC: c++14 global USE flag To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7bfcf13a0f74ad051520b72c X-Archives-Salt: b9891d4a-ce6a-4b0f-a30b-255d922043f4 X-Archives-Hash: eff033e9c6e912120f0f10aeb6a3abbb --047d7bfcf13a0f74ad051520b72c Content-Type: text/plain; charset=UTF-8 2015-05-03 0:17 GMT+03:00 Kent Fredric : > > On 3 May 2015 at 09:11, Maxim Koltsov wrote: > >> LeechCraft has some functionality that is implemented in C++14 and won't >> be available otherwise. >> > > Can you clarify the nature of that functionality? > The Tox support module and email client module (the latter isn't in tree yet, but a good example anyway) both rely on relaxed constexpr from C++14. In some of the newer code I rely on automatic return type deduction and generic lambdas, for example, or some changes in STL. Thus, it's safer to say that basically all new modules that are written (and would be written) since ~January 2015 would require C++14 as a baseline language. Moreover, C++14 allows writing more efficient code (without extra levels of indirection induced by std::function required if one is to specify the return type of a function returning a lambda, for example) in some places. > Shouldn't the USE flag be thus in terms of what that functionality is, not > in terms of the dependency required to provide it? > Since the most general criteria for the functionality is "whether C++14 compiler is available", "c++14" or something like that seems the best fit for the USE flag name. We have "idn" or "gnutls" or "python" etc USE flags after all, not "support_international_names_in_blah" or "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz". Or I just didn't get you here, sorry me in this case :) -- Georg Rudoy --047d7bfcf13a0f74ad051520b72c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015-05-03 0:17 GMT+03:00 Kent Fredric &= lt;kentfredric@g= mail.com>:

On 3 May 2015 at 09:= 11, Maxim Koltsov <maksbotan@gentoo.org> wrote:
LeechCraft has some functionality that is im= plemented in C++14 and won't be available otherwise.

Can you clarif= y the nature of that functionality?

The Tox support module and email client module (the latter isn'= ;t in tree yet, but a good example anyway) both rely on relaxed constexpr f= rom C++14.

In some of the newer code I rely on automatic return type= deduction and generic lambdas, for example, or some changes in STL. Thus, = it's safer to say that basically all new modules that are written (and = would be written) since ~January 2015 would require C++14 as a baseline lan= guage.

Moreover, C++14 allows writing more efficie= nt code (without extra levels of indirection induced by std::function requi= red if one is to specify the return type of a function returning a lambda, = for example) in some places.
=C2=A0
Shouldn't the USE flag be thus in terms of what that functiona= lity is, not in terms of the dependency required to provide it?
=

Since the most general criteria for the fu= nctionality is "whether C++14 compiler is available", "c++14= " or something like that seems the best fit for the USE flag name.

We have "idn" or "gnutls" or &quo= t;python" etc USE flags after all, not "support_international_nam= es_in_blah" or "allow_secure_news_fetching_in_foo" or "= build_scripting_support_for_baz".

Or I just d= idn't get you here, sorry me in this case :)
=C2=A0
--
=C2=A0 Georg Rudoy
--047d7bfcf13a0f74ad051520b72c--