220 39420 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Hamza Sood' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Contract attributes and trailing return types Date: Thu, 26 Jul 2018 13:02:03 -0700 (PDT) Lines: 156 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10211_1294147454.1532635323114" X-Trace: blaine.gmane.org 1532635199 13065 195.159.176.226 (26 Jul 2018 19:59:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 26 Jul 2018 19:59:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCP5NIM2SYKRBPGR5DNAKGQEVFOZF4Y@isocpp.org Thu Jul 26 21:59:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fimQU-0003JV-SD for gclcip-std-proposals@m.gmane.org; Thu, 26 Jul 2018 21:59:55 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id c204-v6sf1384169ywa.8 for ; Thu, 26 Jul 2018 13:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=plpnH59oDqyBewMitTb6pH/UAtO1+LWHQ03DyFVauoA=; b=2LHjl/CoKWRXehTcUq/uHHJYy1oN2T8QGcf8SeXWfqPQoSJxoY1vi3I1aHTdUorsWY 9SxAzpHA6CNqVq3Pr5FEA+u+62OA7gxuhxuGgcJTwYym/8fcO5Hy/l+Vst37esoYYG7T nXTjUiQSrIfXFydTrnF1eX8iP+irQVyfBGtBEIlLocItv+aojFcRjBCtqd0K19zf2zGo pa7xRV4UTbwo+anrIzQnndvMMLl0dwx34cwEyyOiMInLx33cuX9egUDPShWSI7yrOQKt /7gSylrGWdWEpRdU4LCz6b6THgCZc8kW+EhFS4+S21kUYXC6/B6ZKTHzG2X2HukGTQ6b OUHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id: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=plpnH59oDqyBewMitTb6pH/UAtO1+LWHQ03DyFVauoA=; b=dj+Wdj7AGE+2+aE1r6tDrxaYtKPSwBcEtrJlG7wlJqEfjZacI2bbUYMVJbm/Sw6Lrh //KWXHwX0efARCGwmwXg2nDcs3y0VLsY5dHvCvoMEbmDU/iE/Zamp50E0N4PXSVE51t1 MjlxtXaMPqsVXeW/VrgFm/xinznPKpz63UaaIHffG1aGRUvTFNclrEOcR3Ot3OKUA5GB /G7XPJI6uW/s84hMUXRDHkMjyGUujF++yGTRTs9XYFatnopJcWpD8A+4bfhjoL56UkKb LqakHskH6UI/hy8m9/EHQxhqq9MW4FOn103YF2fBXl4b3B/PVcQ/fAFCZ85yzalmdNKM GkwA== X-Gm-Message-State: AOUpUlE7RifOXo5iZT3MWZJMFd9JxQ3J6cs3rcMp0EY4eFp/f0fwFOcs EQOgFb5XsOiFxVRa/3Zjwl6Ydw== X-Google-Smtp-Source: AAOMgpeRbSorDMC7+Gn15ZgkRl2X8njfUdQBl2taXccJrphjHg0VesfghaRlVNMqjW4VjmOyB5nQ1Q== X-Received: by 2002:a81:5a56:: with SMTP id o83-v6mr955670ywb.59.1532635325527; Thu, 26 Jul 2018 13:02:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:a1d3:: with SMTP id y202-v6ls180314ywg.39.gmail; Thu, 26 Jul 2018 13:02:03 -0700 (PDT) X-Received: by 2002:a81:a611:: with SMTP id d17-v6mr36162ywh.2.1532635323737; Thu, 26 Jul 2018 13:02:03 -0700 (PDT) X-Original-Sender: hamza_sood@me.com X-Original-From: Hamza Sood 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:39420 Archived-At: ------=_Part_10211_1294147454.1532635323114 Content-Type: multipart/alternative; boundary="----=_Part_10212_1566364973.1532635323115" ------=_Part_10212_1566364973.1532635323115 Content-Type: text/plain; charset="UTF-8" If I'm interpreting the current draft standard correctly, it looks like contract attributes don't work particularly well with trailing return types. E.g. here's an example from the proposal, re-written with a trailing return type: *auto f(int x, int y) [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]] -> int;* The return type ends up really far away from the rest of the function declaration, which makes it very difficult to spot. I think it'd be better if contract attributes applied to a trailing return type are considered part of the function declaration, which would mean that the above could be written as: *auto f(int x, int y) -> int [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]];* -- 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/b39be2a8-c0c4-4887-a4ad-d11a50107aa9%40isocpp.org. ------=_Part_10212_1566364973.1532635323115 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I'm interpreting the current draft standard correct= ly, it looks like contract attributes don't work particularly well with= trailing return types.

E.g. here's an example from = the proposal, re-written with a trailing return type:
auto f(int x, int y)
=C2=A0 [[=
expects: x>0]]
=C2=A0 [[expects: y!=3D0]]
=C2=A0 [[ensures result: result > x+y]] -&=
gt; int;

The return type ends up really far away from the rest of the fu= nction declaration, which makes it very difficult to spot.

I think it'd be better if contract attributes applied to a tra= iling return type are considered part of the function declaration, which wo= uld mean that the above could be written as:
auto f(int x, =
int y) -> int
=C2=A0 [[exp=
ects: x>0]]
=C2=A0 [[expects: y!=3D0<=
/span>]]
=C2=A0 <=
span style=3D"color: #660;" class=3D"styled-by-prettify">[[ensures result: result > x+y]];

--
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/b39be2a8-c0c4-4887-a4ad-d11a50107aa9= %40isocpp.org.
------=_Part_10212_1566364973.1532635323115-- ------=_Part_10211_1294147454.1532635323114-- .