220 35853 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Output parameters Date: Sun, 10 Dec 2017 17:48:06 +0000 Lines: 85 Approved: news@gmane.org Message-ID: References: <1c1bb50b-2d59-4247-a158-158065fb1a9a@isocpp.org> <0c471d5c-b9b2-40f9-a2bf-908edbb1f272@isocpp.org> <17e3b13c-eb1b-fc2c-590e-3d394f164f9a@wanadoo.fr> <1c8e3ec4-6c5f-43db-bb6e-131d725f7ba4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403043e9f80329b2d056000050c" X-Trace: blaine.gmane.org 1512928086 10643 195.159.176.226 (10 Dec 2017 17:48:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 17:48:06 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBV7GWXIQKGQEA74BCXI@isocpp.org Sun Dec 10 18:48:02 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f199.google.com ([74.125.82.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eO5hp-0002Ze-Ve for gclcip-std-proposals@m.gmane.org; Sun, 10 Dec 2017 18:48:02 +0100 Original-Received: by mail-ot0-f199.google.com with SMTP id f62sf8924891otf.6 for ; Sun, 10 Dec 2017 09:48:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1512928088; cv=pass; d=google.com; s=arc-20160816; b=mVzBSsCiRnFfIGgqVxWk/3bM8c4sDhkeCMoxkSp92+k7tg7hBrX7riS7GbBSjmLmaX N7Ln2oh4uH5poJXC8Wa9QFFHo9dRYGAU6XCT6SAolxl6HVHv2hfkiEn92hUJbz2dNwBb 2t+w8XWszYN7Z6eESShR8mWZIF84Tn6IvtPb5y2H0rl6ydBbwDYsFh4PERLWf4mytTSo yRhdlr3uDyknkYozsXQDL1NYpfjvgwkWxduP1yMNrkJk1qEVhglGuaCbnZzYJB6QXMz+ ssWr4jMv1kk3hrK13t/BuQd8vtyBIATXDky+uJynxTVb+sXpjti9gC6BSxY6v5i86idv Krug== 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:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=XRZ4/T0Ls46E+KFZJttoKr3f/wo+1Xq8eSi9UkO2DuU=; b=s9/bjYV+DGfH2pHY68OZziR24ntzd+P97ATNSdd5ygJPzocJ5HqG0a4JEXw9axqf5Y MUYr94Kbh3AIo5GPs5j3ng8uzNfTljFwv4zkvrHxkuJJEp+irSkSwv0YN+FCniGox1Pc vIQCbJes0WLT2tH7IPGt87pQT5Aann4kK/9SijrFfMYws0KTnhL/p6eZ3xA7dKgzSJtk w5nlaKhoqd8pL0VwE74m+Y/fsTG0pLwq2tL+VswO0unhBvwokoxd5ROZOATdU7ldGdl3 UaNxlafNP+nYJqrcQqEHPb84x76ClWrap1R2uH1vy099bgWa8rbU/akbykl+GunO1Hrj THJA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E/T92URB; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE 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:in-reply-to:references: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=XRZ4/T0Ls46E+KFZJttoKr3f/wo+1Xq8eSi9UkO2DuU=; b=Ab5UU94dDBep6GyxMWVxdlshed3duCFxchhRwCmq2urIM6K6rDVEPgfDeBdW/eUFIt mBP5698jcRVjji+SC26SXzD4aTzN1hs2ooZy5YPlFw2PG3DcXsjStQzCLFFLjiWBVbx6 o7+/CpH2HMOv5djUjM0kLWIdLTfiiGf2yAgpmd4GuqMTnoGsmfRznkN2agUXRrqChKD0 rbUlj73nKp0KIIkpkg2yPKCwFFlak7+5k7B327QgIU1I0QoDoYK+wzVNAMOecDoJ/J6d 4KjgpGECRaMjLXHpRypN7lEC59C7wEbK8oEoq8+sm5CVuxsJqTIgwRSZBSh5k6HCIIEp +mrA== 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: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=XRZ4/T0Ls46E+KFZJttoKr3f/wo+1Xq8eSi9UkO2DuU=; b=tosbFz9KTaALOZK3NFET9loi3HSSkeYzNPMBUFWX1Qd9gzH2jW/YBYBIEmZ0q8Npeb t5eEiy45+dRcQXsH3VSWoYihRLtMZE1QCSyyusfOTlzbytybbu8ZKKF1j4cqNaTDhHdx zgJGOAcpfVUn0kH2vnWVge6UtkQa8YF4v+P5cgU03to3nsJy1/0bPOZxM8OOYZTVaCMo xGyZsjZH55CHs8IPEeW5CcOxpLAzFXRyrP3bm9FUMKPdh4zEnaZOyGmpOnzDhbYCsSEl tCSrJzvn8xbNbxVV+orxgIiL9868EH2E683eWpztCQcbDrtp3L99GO/PYPlsw8VXdq46 bsVQ== X-Gm-Message-State: AJaThX7YtydkSDWiZGHx0OwfF61wuW9+0n+RQHjS3I74XAvMyvEokF+0 g5oW2wEp9i9RO9qLXgpC1mDXZA== X-Google-Smtp-Source: AGs4zMY8KZlTkMgF0k717keQ6J/WikgzYTPVrih/UxPfgkR7vEs2XjNYRO5wlW9nVSR5M3ZFtNjLMw== X-Received: by 10.202.81.129 with SMTP id f123mr19921970oib.51.1512928088898; Sun, 10 Dec 2017 09:48:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.73.132 with SMTP id w126ls1585763oia.8.gmail; Sun, 10 Dec 2017 09:48:07 -0800 (PST) X-Received: by 10.157.22.183 with SMTP id c52mr31042244ote.317.1512928087439; Sun, 10 Dec 2017 09:48:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512928087; cv=none; d=google.com; s=arc-20160816; b=gsf/Hwqv18xGkFKYep91GmwbAmu9iKqElDtugSuNB9c6NdApAHEifG6uxQFYGEM0nG ziIivj5tdWg9cx2OKAE3s+mavtLrJuCgSQQCOQNpRdSd7zILBJWNYt3utCXgzo4qtl1a abmHviWb62aoecaPWu2tpMfG9peNuvLBzN9q3Q0Q487zH4onW6GjgjbgsCctADLSZgKJ +faS6MFZpB9criQ/PeRwjtqP7JIEUl4wl995kvTgRdorpnTPsvFY0FYgm8h/LGC0GSEh zzCNdGOJhqxJxFrumgmlep+68H+HVhHLK42svcBRl8qVibHEh5eR2YF/4VBWPU4mCzJe BvyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=ZgVEBaTOwDOKC5/cctHp9HjRqeZEIMnmlrug4dHXdEE=; b=Ew5rHapmWTNl5NHhfyzo3Jf/dZnOmhsgOZFWsz5OX/OOfkBQ9UBp6EdSvwSOnmN9H7 JhwC3RktQrHYqj2v6WmVNXP/QRN0ulBMQ/uqrL55IElXBNdiKR0YiWr9LZZXSv1zgkVw ZpV/KG18E51ChGTfw/1goPvIDB4cHb49r1xsovmGnr7+GYGMxk+Q3kZu+A/gjHQDv6jP 8soZGfKhk6undVFgdWLABW2Ga/p7DHb3jKGtxISag0NA2bZsMVL4/O3PbkPEY+H67Ikc Njero/mTZloYjcWJrx0MudddtoqHpsrKEP7oounQNJt6NAHLLjF22ooeK3jgJrxdFFwL eGig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E/T92URB; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE 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 z7sor4818132otz.42.2017.12.10.09.48.07 for (Google Transport Security); Sun, 10 Dec 2017 09:48:07 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.157.85.4 with SMTP id l4mr31316310oth.239.1512928087020; Sun, 10 Dec 2017 09:48:07 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sun, 10 Dec 2017 09:48:06 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sun, 10 Dec 2017 09:48:06 -0800 (PST) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E/T92URB; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:35853 Archived-At: --f403043e9f80329b2d056000050c Content-Type: text/plain; charset="UTF-8" One-off return types often occur... the first time you use them. Then, the next time you use them, which is often the case later down the line, you're tied to using whatever approach you used the first time unless you want to either be inconsistent or introduce breaking changes. I think of this as a DRY-trap. If you are to keep repeated code to a minimum, you need to make decisions early on such that you don't end up forced into repeating code. For example, with strictly output parameters, you need to create those variables before the function is called (and if you call this function in several places, this means repeating). If you want to use an unnamed struct, you have to do the same thing unless you auto it out (but then you might as well just name that struct and be done with the matter). This argument only applies to the justification "it's only used once". There are other justifications, such as resource usage (covered by Vincente) and scope control (*{ cheap a; {expensive b; do_something(a,b); handle_b(b); } use_lots_of_resources(); handle_a(a); } *) for which I have no rebuttal. They're completely valid. I'd sooner go for a proposal that somehow adds some fairy dust to make returning equally as effective in these outlying cases, than one which standardises (and thus legitimizes) use of out parameters for the foreseeable future. Though if the former is even possible, whoever comes up with it should probably prepare to receive a lot of hate mail from compiler writers. -- 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/CAC%2B0CCP%3D5yjgToSCFpjn6E3pasweJhj_HuyxwJ4C1k2h4cFtfA%40mail.gmail.com. --f403043e9f80329b2d056000050c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One-off return types often occur... the first time you use them. = Then, the next time you use them, which is often the case later down the li= ne, you're tied to using whatever approach you used the first time unle= ss you want to either be inconsistent or introduce breaking changes.
<= div class=3D"gmail_quote" dir=3D"auto">
I think of this as a DRY-trap. If you are to keep repeated co= de to a minimum, you need to make decisions early on such that you don'= t end up forced into repeating code. For example, with strictly output para= meters, you need to create those variables before the function is called (a= nd if you call this function in several places, this means repeating). If y= ou want to use an unnamed struct, you have to do the same thing unless you = auto it out (but then you might as well just name that struct and be done w= ith the matter).

This argument only applies to the just= ification "it's only used once". There are other justificatio= ns, such as resource usage (covered by Vincente) and scope control ({=C2= =A0cheap a; {expensive b; do_something(a,b); handle_b(b); } use_lots_of_res= ources(); handle_a(a); } ) for which I have no rebuttal. They're co= mpletely valid.

I'd sooner go for a proposal that s= omehow adds some fairy dust to make returning equally as effective in these= outlying cases, than one which standardises (and thus legitimizes) use of = out parameters for the foreseeable future. Though if the former is even pos= sible, whoever comes up with it should probably prepare to receive a lot of= hate mail from compiler writers.

--
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/CAC%2B0CCP%3D= 5yjgToSCFpjn6E3pasweJhj_HuyxwJ4C1k2h4cFtfA%40mail.gmail.com.
--f403043e9f80329b2d056000050c-- .