Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!ctrsol!ginosko!uunet!odi!cass!benson From: benson@odi.com (Benson I. Margulies) Newsgroups: comp.lang.c++ Subject: Re: Default argument values Message-ID: <401@odi.ODI.COM> Date: 26 Jul 89 11:55:39 GMT References: <43253@bbn.COM> <20077@paris.ics.uci.edu> Sender: news@odi.com Reply-To: benson@odi.com (Benson I. Margulies) Distribution: comp Organization: Object Design Inc., Burlington, MA Lines: 102 In article <20077@paris.ics.uci.edu> schmidt@glacier.ics.uci.edu (Doug Schmidt) writes: >In article <43253@bbn.COM>, lpringle@bbn (Lewis G. Pringle) writes: >>In article fox@cs.cs.columbia.edu (David Fox) writes: >>>The way to do this is to allow caller to name the parameters >>>the way Ada does: foo(parm1 = a, parm3 = b, parm2 = c). >> >>I second the emotion, but it may be harder than it looks. What your are >>describing (I think) are called keyword parameters. The difficulty, >>is that they impose even more ambiguity into the language. Default params, >>together with overloading, and conversion operators, already add >>lots ambiguity - keyword paramers would make things even worse. > >There's also another problem. Allowing ``named parameters,'' a la >Ada, weakens information hiding, since formal parameter names are now >visible *outside* their original scope! > Not true. In Common Lisp, it is possible to decouple the two. (defun foo (&key (:x 1 y)) (+ y 1)) means: - call it like (foo :x VAL) - bind a variable named "y" in the body. - Default to 1. C++ need "merely" design a parallel syntax. >IMHO, named parameters are another Ada (mis)feature that adds >gratuitous complexity to the compiler and programmer without providing >much value-added benefit. If the language didn't have optional params with defaults, I would be sympathetic to adding neither those nor by-name parameters. However, as it is, functions tend to become incomprehensible as they are overloaded. Constructors are particularly subject to this abuse. One sees (even in the documentation from AT&T) substantially different behavior triggered by subtlties of the argument list. I believe that the problem results from a particular limitation. Often, I desire a family of functions with nearly identical content but different parameters. I can write them in C++ as a bunch of inline wrappers and one body function, but inlines don't always work, and I begrudge the procedure call. In PL/I, this was addressed by multiple entrypoints. A standard Multics PL/I cliche was: procedure full_interface (x, y, z, q, r, s); ... goto start; entry quick_interface (x, y, z); q = qdefault; r = rdefault; s = sdefault; start: end; Optional parameters attempt to address this case. However, they lose the self-documentation of the different entry names. Constructors are particularly plagued by this. The experience in the lisp community was that optional arguments are often the route to disaster. Who can remember how many zeros to supply to get out to the critical argument I need today? If you are lucky, the optionals will have types without inter-conversions, and then errors will be obvious. But if there are 4 optionals in a row that are either numbers or pointers, then you can have one too many or one too few and never find out till the bridge falls down. In a word, "unsafe". What might a syntax be in C++? Its not obvious. A keyword seems to be needed. int x (byname (name1, default1, var1), (name2, default2, var2)) { If "var" is omitted, then name is the name. If default and var are omitted, then the parens can be omitted. How would one call it? That's the ugly part, I fear. x (name1:=val1, name2:=val2) would serve. Benson I. Margulies