TIP #103 Version 1.2: Argument Expansion Command

This is not necessarily the current version of this TIP.

Abstract

This TIP proposes to add a command that can perform argument expansion in a safe and efficient manner.

Introduction

Many commands take a variable number of arguments and often you find yourself with those arguments in a list. This list must then be expanded into individual arguments to the command. This is currently done with eval:

eval destroy [winfo children .]

This is a bit obscure and also very error prone when the command becomes more complex. It is also inefficient and not object safe, why a command specialised in doing this would be better.

Rationale

There have been suggestions of introducing some new syntax to Tcl to handle argument expansion. That is a big and controversial step, and not anything this TIP wants to meddle in. A command can improve every point where eval has shortcomings and thus give a good result with less means.

Such a command can be done in several ways and below the choice in this TIP's specification is defended.

As examples three statements are used which will be repeated for different alternatives. This is the eval version:

eval destroy [winfo children .]
eval button .b $stdargs -text \$mytext -bd $border
eval exec \$prog $opts1 [getMoreopts] \$file1 \$file2

With the proposed command they become:

expand { destroy @[winfo children .] }
expand { button .b @$stdargs -text $mytext -bd $border }
expand { exec $prog @$opts1 @[getMoreopts] $file1 $file2 }

An alternative to having a local syntax is to point at the arguments that should be expanded, either by index:

expand {end} destroy [winfo children .]
expand {2} button .b $stdargs -text $mytext -bd $border
expand {2 3} exec $prog $opts1 [getMoreopts] $file1 $file2

Or by some flag mechanism:

expand destroy + [winfo children .]
expand button .b + $stdargs -text - $mytext -bd $border
expand exec - $prog + $opts1 + [getMoreopts] - $file1 - $file2

Those lack in writability/readability/maintainability in a disturbing manner.

For the choice of local syntax the first rule is that it should not viol