220 19922 article Path: news.gmane.org!not-for-mail From: Max Truxa Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default arguments Date: Tue, 18 Aug 2015 23:02:01 -0700 (PDT) Lines: 61 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_32_1452366758.1439964121460" X-Trace: ger.gmane.org 1439964131 18133 80.91.229.3 (19 Aug 2015 06:02:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 06:02:11 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD27LKFOY4DBBWVX2CXAKGQEOBEKAQY@isocpp.org Wed Aug 19 08:02:05 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZRwRo-0005Lg-GN for gclcip-std-proposals@m.gmane.org; Wed, 19 Aug 2015 08:02:04 +0200 Original-Received: by ykfw73 with SMTP id w73sf171967755ykf.2 for ; Tue, 18 Aug 2015 23:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maxtruxa.com; s=google; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type: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=B+zlf/sww064UsF4rh0RMjaW4HaJOR1/FVliwAs81fI=; b=JvJLBLJOhE1gejpqn69SkKQWCk3u0o9jdkWQ4on97MBxkfFZMqXRF42rOgwYfz01EZ xzONLtM2MNMw7+Rc9NpowZ995itR26pSBZJShs2nPKLNwjgMTyB0MxHSnefxH+vyPXiQ rAzE3+wdjocFjTbmft6dTdW/FnxIGbC0bRhxE= 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:message-id:in-reply-to:references :subject:mime-version:content-type: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=B+zlf/sww064UsF4rh0RMjaW4HaJOR1/FVliwAs81fI=; b=I3WY/dibWDLVdp7yUlv14qxFtLJs724Tx2q8FtVzC/BMRKqqk0FxIs5Rxz7Eyv8r/i vAwpO/la/db6miSYg/bkqCyZundb5JReYi6purtelAUwMmgWKJq8AAiklpXtuJNE08uz 5hZ32kqJBxUehMhtL7/8ZkL3AfxQvCjPGGDJ4WVC2uF/A7lw1wpjzMsB2lfdmObJkDuW P2Sn4qQb/VkmBiahrTpvTovu11q0OCPg0Bllb2SaSRQIxPMwmZ1GPD0Fj1MH6CJzadi4 XrOD0hEBrbqY/GU6B92+9ItJSTC0MOH9iexF4+KPzqTLI9Vt2smVoLVPnS+pJeLlvJQO BIMA== X-Gm-Message-State: ALoCoQm/vt1EuV/1wYz3SnEmlXGhrfYpWU1UnUfp/44FKw7eNPCK77C5AF6P0FfEzBp2TjTuFKfT X-Received: by 10.52.176.199 with SMTP id ck7mr9070704vdc.7.1439964123206; Tue, 18 Aug 2015 23:02:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.38.11 with SMTP id s11ls3518490qgs.20.gmail; Tue, 18 Aug 2015 23:02:02 -0700 (PDT) X-Received: by 10.140.102.50 with SMTP id v47mr131064qge.14.1439964122056; Tue, 18 Aug 2015 23:02:02 -0700 (PDT) In-Reply-To: X-Original-Sender: me@maxtruxa.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:19922 Archived-At: ------=_Part_32_1452366758.1439964121460 Content-Type: text/plain; charset=UTF-8 I have to agree with Matt Calabrese completely. As it was already asserted named arguments are not going to happen anytime soon (if at all). Earlier in this thread there were workarounds listed which are more or less comparable to the proposal in their effect. I would like to elaborate some more on one of these workarounds, as it can be mapped pretty much 1-to-1 to the proposal and it happens to be the solution I employ when encountering this kind of problem. # Current workaround. struct s { static int const default_a = 1337; static int const default_b = 4096; s(int a = default_a, int b = default_b) : a(a), b(b) { } int a; int b; }; int main() { s x; s y(42); s z(s::default_a, 42); return 0; } See working code here: http://ideone.com/OKtbuc # Using the proposed syntax. struct s { s(int a = 1337, int b = 4096) : a(a), b(b) { } int a; int b; }; int main() { s x; s y(42); s z(default, 42); return 0; } The current solution has a number of drawbacks. 1) It's unnecessarily verbose. 2) It's easy to mess up for parameters that have the same type. (`s z(s::default_b, 42)` - Oops, passed `default_b` as `a`.) 3) When looking up the actual default values there is one more hop to make. It's not sufficient to look at the function declaration but additionally we have to look for e.g. default_a. -- --- 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/. ------=_Part_32_1452366758.1439964121460-- .