220 39101 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr! or constexpr(false)? Date: Thu, 12 Jul 2018 09:05:37 +0200 Lines: 214 Approved: news@gmane.org Message-ID: References: <20180711072840.5177422.61062.57260@gmail.com> <73b413ed-cfef-4174-ac91-51f1eff0274d@isocpp.org> <07767bd5-cd9f-4b9a-bee4-076ab043ccaa@isocpp.org> <1d91ded8-04f8-4306-9ee3-5ca808b91719@isocpp.org> <20180712013408.GA14754@noemi.bahnhof.se> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003600a00570c7fe80" X-Trace: blaine.gmane.org 1531379025 21622 195.159.176.226 (12 Jul 2018 07:03:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jul 2018 07:03:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBTX3TPNAKGQENQPUPPI@isocpp.org Thu Jul 12 09:03:41 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fdVdc-0005Xj-GZ for gclcip-std-proposals@m.gmane.org; Thu, 12 Jul 2018 09:03:40 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id k7-v6sf24602023iog.2 for ; Thu, 12 Jul 2018 00:05:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1531379151; cv=pass; d=google.com; s=arc-20160816; b=EDInhPj9Qneo6tUmaUUjiQsurrxRGhJTGt8ygj+GKfAh1gj82HrlQxnVdzkjTIk71l bpMYPefSBlJAvkjahJDsXOj1pbTjizsZVY5KbgWL7VBCpZ4nMvUXYU1kNHJvbANOJpTc Y4zj56skvVg59/c0liVDEp/ZQLx3YT8iw9H156Y3sUErpJAECiXw/5F1+I3ksq46Jc+1 ErBS61lkW1M+41MPIxYaQO+bvfOtbwgOwER6BjayKXyar1m0Y8+/vTvHwBCQtqk7LRgE wsr5azwaEs3PrXz9x+FaACVcFjn+3buCZx3tsEtkcBjAckKSptBq9HxixylMK4UhbI/M 98Jg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=Wb8UNYYembnFAaca6QWNvzeU8JPDjstWeiBK+FJkkXc=; b=tV/XEp9AeH+9VVSCJZ7JuWXZOG7GI08J//yzm3aK8Nt5kWEKuMDA8cDWUorD85DRS/ 2hpZp5mfB+PUWJlAQ+xyqyIlVJN5mBW/dHGyjWnn2S7D/w4ZLtzYbn+cecCSFtpFp5/6 mgcz0CvPkbrrmJpVaD3q35p9v4fHXPkBvQX0/4AMtwdc53y12RFFOF0ImG4DwtW3e/ix XHf/NMnt4GluQZACKhm5BCbcTnLsRIJI4j18SCR6iN5YVUjkxHGTw8eGB+iXhaS4u1Xl EZf3RMMbXHruNVmbYc4zTIwcQrDxr/N6tmMPqGP382nvzsmxGQ/ni9iRkxGCbqEhtOF+ N7Pg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YtHyHjY0; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Wb8UNYYembnFAaca6QWNvzeU8JPDjstWeiBK+FJkkXc=; b=A7Pt/myQJvyO20LVFe0bFOmP8vGD4drQf5zcOUqhtEh42/DE9GKG2vCu9xLdEEICRC +T3Nd4TibWPilFmG+/liE/Cedyn4U/9Ns1l3Z8CBwG30Z5gMuQoRF2502vvh3JQuOZTQ MWnPvhZUxqdfv68XnpUrKYCQdba3nCdnT0eyMhmPp024DSE1K5nhUs4FqQa9Pef6+7SE Br/lS1ReZFtHcbP7/Dhs4ClhHQXcE0CbfLQnwu5QgpopgLNOlZM/0UqmNY3Jhij3y6lP L+APi3uLKXw+/qan7wACPCD+8VoKoze9a+5geAiZfCllzQMP+jyk5Pi6FmFJhUg/l3dU L1ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Wb8UNYYembnFAaca6QWNvzeU8JPDjstWeiBK+FJkkXc=; b=AhesxWeNXvW2ObaVKQ1xOa7wJRSlUiQFJlQbL7XBkjwfOySDJ17NZrJNWe2Bg2J6lA OIGRVxU4s6stZRM7EyMbR5KCnuer+ng+vrltBBZkawqtwJPPu3M8hvTUGhP4YeieDSrF aB+wg1ortql1HtOX6t9xpMe2Hd+n0Wro+ii7EDo+JrBIWqJWjMbPpsVC1l55eNWhV+Ta NZcCznkGx4pfe0PLBbb/wpCIUT0o69WmRPsvtclOtx2Y3iCQ+mR+0QowVxbSjmJv8mO+ R1rynSGvxAJ0u42amOHVUvWwB4WLEp6MpRzzZ+4Bvx5W61x14qnbbn2elst/o3ctuIlk mO/Q== X-Gm-Message-State: AOUpUlFCvkTGlJ53EP3S0Vmu5lhgFWgbiB4DgCvwsF9pTkz3fBvrGdPa VceEEld5Iq0oj359ab6KMlrAHA== X-Google-Smtp-Source: AAOMgpe+ALpdg7ZWsVx0xnx5wfn/QM23egTJ3KNRVnBn7rOflfmz8pepz5R/Op3egvSPa8trJ8GcMw== X-Received: by 2002:a24:3692:: with SMTP id l140-v6mr317052itl.11.1531379151048; Thu, 12 Jul 2018 00:05:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a02:b799:: with SMTP id f25-v6ls1922613jam.6.gmail; Thu, 12 Jul 2018 00:05:49 -0700 (PDT) X-Received: by 2002:a02:b522:: with SMTP id l31-v6mr573439jaj.104.1531379149905; Thu, 12 Jul 2018 00:05:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531379149; cv=none; d=google.com; s=arc-20160816; b=T5qEQLfVJiV+Pm7egrSUmezYeZSH2B/GMjTGD8YuxzRCYTqYM9HwqmJhpJYk7sBclj Pbc7JDXQYV83TcOT4R4fS93mg6obuFJhfUPGo0tTzjAEPynkuVsSqqcCMfw4sFQi2+Xx KD0vcRiv6EACPOMOY0ZxLspEhiCLvY1ElFZHLE5FFCTbVIIxHbBKA7fpzbhaJfLE4j/w 0N007mxtIWVuCicoOdwwJRUI9xooYX1beq7+ITemkPd1o+blEfFuU+Gz04HhMAGlWO8U TBrCrQYwibQ01DjB8e+g9UYL1m3KUT5bM+NR0irZBF3167c9E+/5+Ot7pmruNvJSW4Rk m5cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=yB1ouG/BLfVWcfiHRr9Z5IydaoFYRKevT142g1N4HNs=; b=S29o/bh0rrDmGc7iC9uKkUzf8XEICMkwjMCFI91N5SvUBHhpQch5YGvc4QWoPfhLpz NySareeF7Mg2In4BC2Eg3fWTbmWJL9zRwjPBAxdYWtdy8+BhG2U0rGbdWUxoRJLS7x4W 1SBzIO8lcusufk1FSK6cQEITcxYDfzvg6jpsR9kh4uTyI48llfu4Df4gTcJBwrU68YsM u8KFTIGsFW6PKQyfT4xEEfuW4Q2MckNB8fov64als3kZ01380dw28xS4GSMCtp0qPGVY TkSM3a8eR4KsKcF8ZczFX1O5HhHQCbyPYjJ1iyNyFB2lvODOOZLBv6CFOjsUr4NS3sx3 h9oQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YtHyHjY0; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id o15-v6sor5340251ioo.129.2018.07.12.00.05.49 for (Google Transport Security); Thu, 12 Jul 2018 00:05:49 -0700 (PDT) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a6b:8828:: with SMTP id k40-v6mr616037iod.68.1531379149306; Thu, 12 Jul 2018 00:05:49 -0700 (PDT) In-Reply-To: <20180712013408.GA14754@noemi.bahnhof.se> X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YtHyHjY0; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:39101 Archived-At: --0000000000003600a00570c7fe80 Content-Type: text/plain; charset="UTF-8" On Thu, 12 Jul 2018 at 03:34, Magnus Fromreide wrote: > On Wed, Jul 11, 2018 at 08:26:44AM -0700, florian.csdt@gmail.com wrote: > > > > > > > > > > And if it could do that, why not just let the names be accessible too? > If > > > we're relying on the existence of some objects, then rely on it > already. > > > And if we're going that far, why not allow the `inline!` function be > able > > > to return *for* its caller rather than *to* its caller? Or affect its > > > caller in other ways. > > > > > > You can see that we're quickly moving away from being a mere > "function" > > > and becoming something else: a named series of statements that get > > > copy-pasted into code. That might be a useful feature or a confusing > one. > > > But this half-state between them that you propose is exactly that: a > > > half-state. Neither one thing nor the other, the construct is only > useful > > > in a trivial number of instances. > > > > > > > @Nicol: > > Here, you're completely right: those are not really functions anymore. > > > > However, I would avoid putting names in the caller scope: this more > > annoying than it is solving issues. > > Keeping temporaries because they are referenced elsewhere would be the > main > > goal. > > I would say it was a novel but peculiar way to introduce anonymous > variables. > > inline! std::string_view makeFoo() > { > std::string mAnon(initialize()); > return mAnon; > } > > Thanks to the inline! the string_view is valid in the returned context. This is adding a cryptic language feature in order to carry a dependency through a reference in a hidden way. It is the exact opposite of all the good things that have happened to c++ since 2011. Value semantics, good. Tidying up after dangling references, bad. Questions: a) how would you express this bizzareness in the standard? b) how would you teach it? c) why do you want to return a string_view here (a.k.a. dangling references mk 2) when you could simply return the string? I'm still waiting for someone to post a real motivating use case. So far none have been forthcoming. Frankly this is unsurprising. Some feature ideas are simply not destined to survive birth. > > template > inline! void anonymize(T&& t) { T aT(std::forward(t)); } > > Use this one like > > anonymize(stack_guard([](){...})); > > Useful feature but somewhat surprising syntax. > > /MF > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180712013408.GA14754%40noemi.bahnhof.se > . > -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbvmG361yaDu0p2QPOMBM8N8CuHD93qbCDs8ZXj9i9K%2Bw%40mail.gmail.com. --0000000000003600a00570c7fe80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , 12 Jul 2018 at 03:34, Magnus Fromreide <magfr@lysator.liu.se> wrote:
On Wed, Jul 11, 2018 at 08:26:44AM -0700, florian.csdt@gmail.com wrote:
>
>
> >
> > And if it could do that, why not just let the names be accessible= too? If
> > we're relying on the existence of some objects, then rely on = it already.
> > And if we're going that far, why not allow the `inline!` func= tion be able
> > to return *for* its caller rather than *to* its caller? Or affect= its
> > caller in other ways.
> >
> > You can see that we're quickly moving away from being a mere = "function"
> > and becoming something else: a named series of statements that ge= t
> > copy-pasted into code. That might be a useful feature or a confus= ing one.
> > But this half-state between them that you propose is exactly that= : a
> > half-state. Neither one thing nor the other, the construct is onl= y useful
> > in a trivial number of instances.
> >
>
>=C2=A0 @Nicol:
> Here, you're completely right: those are not really functions anym= ore.
>
> However, I would avoid putting names in the caller scope: this more > annoying than it is solving issues.
> Keeping temporaries because they are referenced elsewhere would be the= main
> goal.

I would say it was a novel but peculiar way to introduce anonymous variable= s.

inline! std::string_view makeFoo()
{
=C2=A0 std::string mAnon(initialize());
=C2=A0 return mAnon;
}

Thanks to the inline! the string_view is valid in the returned context.=C2= =A0

This is adding a cryptic language featu= re in order to carry a dependency through a reference in a hidden way. It i= s the exact opposite of all the good things that have happened to c++ since= 2011. Value semantics, good. Tidying up after dangling references, bad.

Questions:

a) how would you= express this bizzareness in the standard?

b) how = would you teach it?

c) why do you want to return a= string_view here (a.k.a. dangling references mk 2) when you could simply r= eturn the string?

I'm still waiting for someon= e to post a real motivating use case. So far none have been forthcoming. Fr= ankly this is unsurprising. Some feature ideas are simply not destined to s= urvive birth.
=C2=A0

template <class T>
inline! void anonymize(T&& t) { T aT(std::forward<T>(t)); }
Use this one like

=C2=A0 anonymize(stack_guard([](){...}));

Useful feature but somewhat surprising syntax.

/MF

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isoc= pp.org/d/msgid/std-proposals/20180712013408.GA14754%40noemi.bahnhof.se.=

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbvmG361y= aDu0p2QPOMBM8N8CuHD93qbCDs8ZXj9i9K%2Bw%40mail.gmail.com.
--0000000000003600a00570c7fe80-- .