TIP #288: ALLOW "ARGS" ANYWHERE IN PROCEDURE FORMAL ARGUMENTS =============================================================== Version: $Revision: 1.14 $ Author: Peter Spjuth Andreas Leitgeb Peter Spjuth State: Draft Type: Project Tcl-Version: 8.7 Vote: Pending Created: Tuesday, 03 October 2006 URL: https://tip.tcl-lang.org288.html Post-History: ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes to make /args/ have its special meaning as a formal *proc*edure argument anywhere in the argument list. RATIONALE =========== 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 tcl procedures 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 get simple semantics, optional arguments are not allowed after "args". Optional arguments that precede "args" will be handled as before. This TIP does not, as of now, specify defaulted arguments directly preceding non-defaulte ones. This should be addressed in a separate TIP. SPECIFICATION =============== 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: 1. Assign arguments right of "args" from the right. 2. Assign arguments left of "args" from the left. Handling of defaulted parameters preceding "args" remains as it was (but disregarding the non-defaulted ones after "args"). 3. Remaining arguments are assigned to "args". COMPATIBLITY ============== 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. All such occurrances would need to be fixed. Detecting such scripts in an automated way would be simple and fixing them is trivial. EXAMPLES ========== New style: proc lgurka {args list item} { array set opts {-apa 1 -bepa "" -cepa 0} foreach {arg val} $args { set opts([prefix match {-apa -bepa -cepa} $arg]) $val } # Do real stuff } Old style: proc lgurka {args} { if {[llength $args] < 2} { return -code error "wrong # args: should be \"lgurka ?args? list item\"" } set item [lindex $args end] set list [lindex $args end-1] set args [lrange $args 0 end-2] array set opts {-apa 1 -bepa "" -cepa 0} foreach {arg val} $args { set opts([prefix match {-apa -bepa -cepa} $arg]) $val } # Do real stuff } proc x {a args b} { puts "a=$a, args=$args, b=$b" } x 1 2 ;# -> a=1, args=, b=2 x 1 2 3 ;# -> a=1, args=2, b=3 x 1 ;# -> error: wrong # args: should be "x a ?args? b" proc y {a {b x} args c} { ... } y 1 2 3 ;# a=1 b=2 c=3 args is empty proc z {a {b x} c args} { ... } z 1 2 ;# -> error: wrong # args: should be "z a ?b? c ..." To change "z" is not covered by this TIP. COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows