This is not necessarily the current version of this TIP.
| TIP: | 288 |
| Title: | Allow "args" Anywhere in Procedure Formal Arguments |
| Version: | $Revision: 1.3 $ |
| Authors: |
Peter Spjuth <peter dot spjuth at space dot se> Andreas Leitgeb <avl at logic dot at> |
| State: | Draft |
| Type: | Project |
| Tcl-Version: | 8.6 |
| Vote: | Pending |
| Created: | Tuesday, 03 October 2006 |
| Keywords: | Tcl, proc |
This TIP proposes to make args have its special meaning as a formal procedure argument anywhere in the argument list.
Many commands, specially many of Tcl's built in commands, have their variadic arguments in the beginning of the argument list and their required arguments at the end. An example is [lsearch ?options? list string].
Writing commands in that style is currently a bit cumbersome since you need to do you own argument counting and assignment to variables from "args".
If "args" had its special meaning at any location in the argument list, it would help with such a task, and it would make things more consistent.
To preserve full backward compatibility (when "args" is not used before the last) (see comments) and to get simple semantics, optional arguments are not allowed after "args".
At most one proc argument may be named "args" and can be anywhere in the argument list. Arguments after "args" may not be optional. Arguments are assigned in the following order:
Assign arguments right of "args" from the right.
Assign arguments left of "args" from the left.
Remaining arguments are assigned to "args".
Currently "args" is allowed anywhere in the argument list, and becomes a normal variable if not last. Most scripts probably don't use this since it would be rather confusing, but it might exist.
Detecting such scripts in an automated way would be simple and fixing them is trivial.
Andreas Leitgeb: I just want to clarify, that if someone (against all reason) had a procedure with "args" as a non-last argument-name, then forbidding optional arguments does *not* retain compatibility! That one argument would then still be one list-level deeper than now.
This document has been placed in the public domain.
This is not necessarily the current version of this TIP.