From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61167 invoked by alias); 10 May 2017 09:24:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 60665 invoked by uid 89); 10 May 2017 09:24:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:58e1ace, H*f:sk:58e1ace, H*Ad:U*linux X-HELO: mail-pg0-f44.google.com Received: from mail-pg0-f44.google.com (HELO mail-pg0-f44.google.com) (74.125.83.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 May 2017 09:24:21 +0000 Received: by mail-pg0-f44.google.com with SMTP id u187so13693285pgb.0 for ; Wed, 10 May 2017 02:24:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ViKukMB4UpiQ6B5OIMUvBrqqFfTIJk+2SiAtmLkbVm0=; b=cYMxhFqRLHxFx9JazeFG2BQrzBAZH82BO5sGKlmx4GKjiVvv6DJOHlwRfGE98IzkGY fiNpePwu5KSCh/b6UwFZRr/Ps90pZoPXMkQauEGKKi4Sw5Asbtpw79OhHgSsuD3HqVZL 4+kVaksjRHpJ51Et9nWxoD2WhrzLuGgH7DCvvNO/B1T2j/BAfda+geWzjYnj2lNdp35F GTufaNZ2lT5ZiSOkyBwrmN9OTzkH4X93ZPL0DnCr62L7Ef2k0UHdzANsIOFdqX1BLmQE 3RJiYoWeUa37e7KFiK3c2/wdtgLhSoYxsi+iPweia1nWOlfW9x3NdsdDrA3dk6OOAxyR rVeQ== X-Gm-Message-State: AODbwcALDiR/gKt+Fa2bOqxAsipJGE0MhzXL/o6sGjSpfU+gQXtcvmVS t3VKwQQOmSYS0kYSHE+HLD7LLU3AZQ== X-Received: by 10.84.174.197 with SMTP id r63mr6702888plb.67.1494408262180; Wed, 10 May 2017 02:24:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.79 with HTTP; Wed, 10 May 2017 02:24:21 -0700 (PDT) In-Reply-To: <58e1ace4-2285-3177-8939-2785c920b888@pobox.com> References: <02f991c6-7679-9f9b-aa57-35a25e37acd9@pobox.com> <201705091529.53074.linux@carewolf.com> <58e1ace4-2285-3177-8939-2785c920b888@pobox.com> From: Jonathan Wakely Date: Wed, 10 May 2017 09:24:00 -0000 Message-ID: Subject: Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates To: Daniel Santos Cc: Allan Sandfeld Jensen , "gcc@gcc.gnu.org" , Joseph Myers , Richard Henderson Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00092.txt.bz2 On 10 May 2017 at 10:17, Daniel Santos wrote: > Maybe "constexpr" would be a better name, as it mirrors the C++11 keyword. > When I first read about C++ getting constexpr, my first thought was, "Yeah, > as if they needed yet another way to do metaprogramming!" :) However, I Because writing functions in normal C++ is much simpler and more expressive than writing class templates and recursive partial specializations. Just because there's already one way to do something doesn't mean better ways to do it are bad. > hadn't gone so far as to investigate using this new attribute on functions > since we already have __attribute__((const)). I haven't used this before so > maybe I'm not aware of something that makes it unusable for such cases? > Which of course raises the question if __attribute__((const)) would work out > since it's only currently used on function declarations (and pointers to > function declarations, but I don't fully understand what that is doing in > handle_const_attribute). __attribute__((const)) is not a substitute for constexpr, it's not even in the same ballpark. It says the function doesn't touch global memory, it doesn't mean its return value is a constant expression, so you can't do: int f() __attribute__((const)); int f() { return 1; } int i[f()]; I don't think __attribute__((const)) is useful for your goal.