220 4096 <7c79ca05-607f-40e8-bd51-467363f007ac@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default values in middle parameters in a function Date: Mon, 29 Apr 2013 23:43:50 -0700 (PDT) Lines: 156 Approved: news@gmane.org Message-ID: <7c79ca05-607f-40e8-bd51-467363f007ac@isocpp.org> References: <25d51458-9a2e-4607-9b1a-9d2a7be8df4e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1230_30249893.1367304230614" X-Trace: ger.gmane.org 1367304238 18323 80.91.229.3 (30 Apr 2013 06:43:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 06:43:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKWQ7WFQKGQE5LINDBA@isocpp.org Tue Apr 30 08:43:55 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UX4I7-0004lT-Gf for gclcip-std-proposals@m.gmane.org; Tue, 30 Apr 2013 08:43:55 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id o17sf1148315oag.10 for ; Mon, 29 Apr 2013 23:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=b0g87Bm7ftNKHTIGBnaIcKjjn+3SO11wIghl6V43qrI=; b=LWr30bhbCRs4gbcYxavtB4SWKJfcDfTx7R3p+yTMLP/bumwkGEEC2Avr1Y3OM+fzpi hNZdf+16AIWpO2Hql03fKW6O9Q5nmFrnqJuozHp8UwV4typJUK7cJPApZ6pMKnBgtVFs yk6I1kZuS+jJhDLQ1fadLRrYBqEX3HObSfS5mOxf6IAaoa1muPvk55LtrJItCe+mTG9k nWXRtMXHREJUILlQL8GyHs4n3gp03K41as8GiPmct5/m3QIsbKvZ1u3PnAiAVud2+Fdb u7go2BTJHALnMazFd8EFEeXsnnUu73CHw4rWm9J6ApPk+TywXFkrOKlE3r5yfdtlDz9s f3Ug== X-Received: by 10.182.243.233 with SMTP id xb9mr741786obc.1.1367304234509; Mon, 29 Apr 2013 23:43:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.38.170 with SMTP id h10ls15088obk.54.gmail; Mon, 29 Apr 2013 23:43:52 -0700 (PDT) X-Received: by 10.182.29.8 with SMTP id f8mr73483obh.39.1367304232095; Mon, 29 Apr 2013 23:43:52 -0700 (PDT) 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:4096 Archived-At: ------=_Part_1230_30249893.1367304230614 Content-Type: text/plain; charset=ISO-8859-1 On Monday, April 29, 2013 10:32:40 PM UTC-7, Hariharan Subramanian wrote: > > Default parameters can vary between translation units, which is >> not good for code clarity. They can also cause address-of-function >> problems and binary compatibility problems. An overload set is a >> significantly better approach to the problems that default parameters >> solve. I would rather the user wrote function overloads to handle >> the various cases. Mostly, you can do this in an API-compatible >> manner. So, rather than extend a flawed feature, I would rather say >> "do not do that". >> > > Default parameters are a reality and used extensively. Instead of making a > "flawed feature" difficult to work with it makes this "flawed feature" > easier to work with. > Personally, I don't think that default parameters are a "flawed feature". That being said, the flaws discussed are *not* resolved by your suggestion. Default parameters solve a simple, very specific problem. Function overloading solves a larger, more general problem. I like that we have both. And I think that the problem that you intend to solve, with some kind of "default" parameter, is best solved with the larger, more general solution. Also, with `optional`: void foo(int param, optional value1, optional value2) { type1 val1 = value1.value_or(a1); type2 val2 = value2.value_or(a2); //implementation } void usefoo() { foo(0, nullopt, b2); } That seems to take care of the problem. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en. ------=_Part_1230_30249893.1367304230614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Monday, April 29, 2013 10:32:40 PM UTC-7, Hariharan Subramanian wrote:
Default parameters can vary= between translation units, which is
not good for code clarity.  They can also cause address-of-function problems and binary compatibility problems.  An overload set is a
significantly better approach to the problems that default parameters
solve.  I would rather the user wrote function overloads to handle
the various cases.  Mostly, you can do this in an API-compatible
manner.  So, rather than extend a flawed feature, I would rather say "do not do that".

Default parameters ar= e a reality and used extensively. Instead of making a "flawed feature" diff= icult to work with it makes this "flawed feature" easier to work with. = ;

Personally, I don't think th= at default parameters are a "flawed feature". That being said, the flaws di= scussed are not resolved by your suggestion.

Default paramete= rs solve a simple, very specific problem. Function overloading solves a lar= ger, more general problem. I like that we have both. And I think that the p= roblem that you intend to solve, with some kind of "default" parameter, is = best solved with the larger, more general solution.

Also, with `opti= onal`:

void fo= o(<= span style=3D"color: #008;" class=3D"styled-by-prettify">int param, optional<type1> value1, optional<type2> value2) {=
  type1 val1 =3D value1.value_o= r(<= span style=3D"color: #000;" class=3D"styled-by-prettify">a1);
  type2 val2 =3D value2.value_or(a2);
  //implementation
}=

vo= id usefoo<= /span>() {
       foo(0, nullopt, b2);
}

That seems to take care of the problem.

--
 
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-pro= posals/?hl=3Den.
 
 
------=_Part_1230_30249893.1367304230614-- .