220 29656 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: compiler should infer last semicolon of culy brace block... it makes lambas look better.... Date: Sun, 4 Dec 2016 17:34:59 -0800 (PST) Lines: 120 Approved: news@gmane.org Message-ID: References: <99df401b-562e-424f-9c17-01575f8b47e1@isocpp.org> <5876fa59-f31f-4b93-969a-8ab0437f2f55@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1286_212158984.1480901699600" X-Trace: blaine.gmane.org 1480901703 31545 195.159.176.226 (5 Dec 2016 01:35:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Dec 2016 01:35:03 +0000 (UTC) Cc: wm2015email@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBREISPBAKGQE3DZDBEI@isocpp.org Mon Dec 05 02:34:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDiBF-0007Er-4g for gclcip-std-proposals@m.gmane.org; Mon, 05 Dec 2016 02:34:57 +0100 Original-Received: by mail-yb0-f198.google.com with SMTP id t7sf311741064yba.2 for ; Sun, 04 Dec 2016 17:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=9qSFzsuwlPH8ERyGY0+1UU7LRCHfR+a++nLAge22MH4=; b=WCjGXh6SWTZxEwg811jg80xEj8169oATw9H1RRAS8b2C7EPQD7RgSYArMHI+GQHhRI O78cEC2m9dKml1vCY16ccR0QxOJJh0t5GE31yLUnCWWhdBa7dt7tznNG9S2B15QWLLdD +hKjmejv+8s77fHljs+CNKrOy+TNoDy12iXFQKx4iGFjlwn1tF86RzwWvY1i8vj1Ehxt bqDVU3REmsSu0CJ650UMWC7w7kdAg1KtuIS5OjPl5mEdH7u6sYJgpZfLUpXn+VW1CvgK DyehMQSF7Z5Ui6SaXtLPS8w55jV+4dKyt72mUR2w3BbQqLyMlo7ctl1ApVt/70tRQSb/ BaqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=9qSFzsuwlPH8ERyGY0+1UU7LRCHfR+a++nLAge22MH4=; b=v/MyBD2OMitmLERadjtC3+HQq57vjyxQHRQoDR/b37MJ1ZokGIfXp8p+zpbxfsD13Q YPGjV6lFP/fAUMsLVIIzwQg4nyewnd24Uu8WOmHSyhg6M7CBNSmgPnZpECuJ6UpP3i3h SuQnYKrMJE3d/ncy0qDFXjTkDNmyT6Lx/qAkVFnGl+d7+Em/PQRjLQ8w8PdQ67MJppql d6dXtWo3zmT2LHHi+Heo3Zp6Mef7ZRgVlBR3z4f11xSoDpHDDnKR0keTFRYe4v6iDquZ cn6tcGQWWyNwJ2t1HbiDPNOJF1XNv0UED7PdMqm9MMdty5ZrmCiu5f1JcMdgigpGJQxW GEJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=9qSFzsuwlPH8ERyGY0+1UU7LRCHfR+a++nLAge22MH4=; b=Dqegzorm7p6qzEkyexKPXimlOMQfWLjiQ/zkew4vN2MaWyiNEdaCe9/76vnrvhiHf3 BnGouevxBUTuy+WqJYVS0xFFZt7KNC06g2FW15RDhtWvifjsUallRQvlBOj6GrIsHZVP 8qdcw97m33bpM0w7c8e6a8lUH4WgAMFyicToZSkKvkG5dOgYsqcRjk4/LDtGC3WZwTNr uhLPuwTYpy2ihsBnf7AY1kJ50+QE4aS2rPk/JGHPHWRQYtCdiNmOCuKjiN9CI4N6dm4a LkoQxRpkJqgImvRwgN9Bsi6UZ6LVLqbq2j2PKwc6NuJLdcVjr+IpddnnAkP99N3xOo3g tfLw== X-Gm-Message-State: AKaTC038dnq7VrorP/tSzrJWQav2xl2Q9+KzETtFVvqO6ViAc04Ls00ZPTRtGuoCM+1cjw== X-Received: by 10.13.198.69 with SMTP id i66mr14100604ywd.30.1480901700837; Sun, 04 Dec 2016 17:35:00 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.23.193 with SMTP id j59ls25903103otj.24.gmail; Sun, 04 Dec 2016 17:35:00 -0800 (PST) X-Received: by 10.157.18.211 with SMTP id g77mr3581311otg.14.1480901700062; Sun, 04 Dec 2016 17:35:00 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:29656 Archived-At: ------=_Part_1286_212158984.1480901699600 Content-Type: multipart/alternative; boundary="----=_Part_1287_1252500515.1480901699601" ------=_Part_1287_1252500515.1480901699601 Content-Type: text/plain; charset=UTF-8 On Sunday, December 4, 2016 at 6:37:19 PM UTC-5, Giovanni Piero Deretta wrote: > > On Friday, December 2, 2016 at 8:20:46 PM UTC, Nicol Bolas wrote: >> >> On Friday, December 2, 2016 at 3:15:43 PM UTC-5, Jakob Riedle wrote: >>> >>> That might be `void` or it might not. There's no way to tell. >>> >>> >>> Well, there is also no way to tell, whether "return dosomething2()" is >>> void. >>> Look here for an Example . >>> Does this even answer the concerns that you had? >>> >> >> My point is that it isn't clear whether the user *wanted* "return >> dosomething2()` or whether they just wanted to *call* `dosomething2()`. >> That's why, if we're going to elide the last semicolon in the block, doing >> that should not change the meaning of the last statement. >> >> > why is that an issue? if the lambda was not supposed to return anything > the result would be dropped anyway. If it is, then either the code works as > intended or the compiler will complain loudly if the returned type is not > of the expected type. > The return value will be dropped at the location where the function gets called, not by the code that called it. Furthermore, this return value becomes part of the functor's calling type if it is deducing the return type. If you get a function pointer from a capture-less lambda, perhaps to pass to some C-based API, you'll get a very confusing compile error somewhere along the line. Ultimately, I just don't see the point in having a small syntactic change like missing a semicolon have such a radical change in the *meaning* of a line of code. It would be much better for us to just give people good syntax for expression-only lambdas, while letting a missing semicolon not change the meaning of the code. If a multi-statement lambda needs to return something, then you need to type `return`. -- 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/fdaac8aa-fadf-4b29-a23d-93caf4033758%40isocpp.org. ------=_Part_1287_1252500515.1480901699601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday, December 4, 2016 at 6:37:19 PM UTC-5, Giovanni = Piero Deretta wrote:
On Friday, December 2, 2016 at 8:20:46 PM UTC, Nicol Bolas wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
On Friday, December= 2, 2016 at 3:15:43 PM UTC-5, Jakob Riedle wrote:
That might be `void` or it might not. There's no way to tell.

Well, there is also no way to tell, whether &q= uot;return dosomething2()" is void.
Look here for an=C2=A0Example.
Does this even answer the concerns that you had?

My point is that it isn't clear whether the user wante= d "return dosomething2()` or whether they just wanted to call `dosomething2()`. That's why, if we're going to elide the last s= emicolon in the block, doing that should not change the meaning of the last= statement.


why is that an issue? if t= he lambda was not supposed to return anything the result would be dropped a= nyway. If it is, then either the code works as intended or the compiler wil= l complain loudly if the returned type is not of the expected type.

The return value will be dropped at the locat= ion where the function gets called, not by the code that called it. Further= more, this return value becomes part of the functor's calling type if i= t is deducing the return type. If you get a function pointer from a capture= -less lambda, perhaps to pass to some C-based API, you'll get a very co= nfusing compile error somewhere along the line.

Ultimately, I just d= on't see the point in having a small syntactic change like missing a se= micolon have such a radical change in the meaning of a line of code.= It would be much better for us to just give people good syntax for express= ion-only lambdas, while letting a missing semicolon not change the meaning = of the code. If a multi-statement lambda needs to return something, then yo= u need to type `return`.

--
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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/fdaac8aa-fadf-4b29-a23d-93caf4033758= %40isocpp.org.
------=_Part_1287_1252500515.1480901699601-- ------=_Part_1286_212158984.1480901699600-- .