TIP 288: Allow "args" Anywhere in Procedure Formal Arguments

Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2017 Conference, Houston/TX, US, Oct 16-20
Send your abstracts to tclconference@googlegroups.com
by Aug 21.
Author:         Peter Spjuth <peter.spjuth@space.se>
Author:         Andreas Leitgeb <avl@logic.at>
Author:         Peter Spjuth <peter.spjuth@gmail.com>
State:          Draft
Type:           Project
Vote:           Pending
Created:        03-Oct-2006
Keywords:       Tcl,proc
Tcl-Version:    8.7


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 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.


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".


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.


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.


This document has been placed in the public domain.