[comp.lang.c++] Scope Rules for Function Arguments: Extension

dsouza@mcc.com (Desmond D'Souza) (10/20/89)

----------------------------------------------------------------------------

1. SCOPE RULES FOR FUNCTION ARGUMENTS should to be refined, in keeping with
	the philosophy of default arguments.


I think the scope rules of arguments to a function need to be refined, from
considerations of default values for arguments.

Based on Lipmann (p. 124):
  "The argument list is treated as being within the local scope of the function." 
it would seem that no order is assumed among arguments scopes. (I do not have 
the language manual). 

However, in C++, default values for arguments are based upon precedence: you can
only provide defaults for the later arguments (the slightly different rule for
declaring new defaults conforms with this).  Clearly, this requires that some
ORDER or priority be imposed on the arguments when designing a much used function.

Based on this, it is reasonable to want later arguments to have default values
computed from earlier arguments. e.g.

	void married_names (LastName husbandsLastName,
			    LastName wifesLastName = husbandsLastName )
	{ ... body ... }

Note that the quote above does not rule this out. It does not support it either.
Simply requiring that the argument list order be respected in the scope resolution,
seems reasonable, as in :
      {
	LastName husbandsLastName;
   	{ LastName wifesLastName = husbandsLastName
	    { ... body ... }
	}
      }

If ever we get to see NAMED ARGUMENTS in C++, I'm sure these rules could be refined.
e.g. default values can ONLY depend on positional args and not on named args, plus 
the above precedence between positional arguments.  

---------------------------------------------------------------------------

2. A observation about the C++ I/O library and another call for named arguments.

BTW: based on the above argument about designing argument lists so that the earlier
arguments are "more important", I think the I/O library "<<" and ">>" operators
are aren't ideal. It makes perfect sense to have a default value for a stream to print 
to, but does not make much sense to have a default for the THING to print. Yet these
operators have the signature:
	ostream& operator<< ( ostream& os, thing& th);
This makes a default stream argument impossible.

On the other hand, maybe this was forced by the wish to concatenate "<<" calls,
and the inability to change associativity of operators. If I could make ">>" 
right associative, I would use ">>" as the "output" operator,
using:     	ostream& operator>> (thing& thing, ostream& os);
writing:	thing1 >> thing2 >> thing3 >> ... >> cout;
and allowing:	ostream& operator>> (thing& thing, ostream& os = cout); // default is cout.

OF COURSE, having NAMED arguments would greatly alleviate this. Does anyone know if 
these are being considered for the future? Are syntactical restrictions a problem?

Does the same argument holds against having "put" "write" etc. as member functions, 
since you cannot default the "reasonable" argument -- the stream. 

----------------------------------------------------------------------------

Actually, I think streams and the I/O library are very good examples of working
within and using C++. 

Desmond D'Souza



 Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324
 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza