i.e. allow set to set multiple variables at once, where the last one potentially gets no newvalue. The value of the last varname is returned. I've really seen enough of

foreach {a b c} {1 2 3} {}

don't you think

set a 1 b 2 c 3

looks much nicer ? :)

RS Agreed - and it matches the way the variable command can be called. Just a little nit: it seems to become an idiom to rename original Tcl commands into the tcl namespace, so I'd write (testing, so I don't lose the original on repeated sourcing)

if {[info command tcl::set] == ""} {rename set tcl::set}

MSW Good point - I've added it like this as an example to the set page.

DKF - I favour adding TclX's lassign command. It's well known already, and it doesn't tinker with the behaviour of a very basic core command. TIPs 57[1] and 58[2] cover this sort of area as well.

MSW I disagree. lassign's syntax is no bit better than abusing foreach, and that's how it looks like. Having a TIP there (#58 looks fine) is a good reason that this entry is not needed. And I don't think that leaving a core command at a crappy state is a good argument against enhancements. lassign and variable's semantics are different. It would be better that if whatever you used for multiple assignments (and I do favour set, for no incompatibility to its current use will arise!) had the same conventions as variable has, or changing variable to have the same convention lassign has - and breaking tons of scripts.

Both functionalities can be used by themselves, and I think these are no abuses:

foreach {x y z} $threeValues break
foreach _ _ {#some code that runs once and may be left with [break]}

MSW I think it's an abuse because I'd prefer to not have foreachs iteration variables in the calling scope, and thus I treat foreach as if it didn't clobber its calling environment. But that's personal preference. Both the uses you cited as 'valid' uses of foreach are nice obfuscators imho...

FW: I was gonna suggest that, but that's a more dramatic change. In an ideal world, both would happen, but Tcl gets changed extremely slowly, so it'd be idealistic to suggest both at once ;)

rmax: I think both changes would even be allowed in a minor release, as the foreach optimization doesn't change behaviour at all, and the set extension only makes a backwards compatible change.

DKF: There's a currently Draft TIP on extending the set command, and it is really unpopular with the TCT. We're kind-of hoping the author will withdraw the TIP sometime so we don't have to be mean and vote the suggestion down. FWIW, the consensus seems to be that the set command is inviolate, even across major versions.

DKF: The TIP in question is #58[3] and it looks like it will be rejected outright (as I write this, the vote is in progress but there have been many votes against and none for.)

DKF: Yep. Utter rejection. Anyone wanting to modify set had better not rely on core mods to do it!

DKF: Try TIP #57[4] instead, though perhaps recognizing the foreach-as-multi-set idiom and getting smart with it may be done at some point too.

FW: The thing is, the current idiom is just as understandable, already in use, and doesn't add a new command just for sugar.

DKF: If we put TclX's lassign in the core, I think you'll find that that does rather more than the foreach idiom. :^)

PWQ12 Sep 2003, How about we implement this by thinking outside the square. One the one hand, most people just want to remove the trailing {} from the foreach command. On the other, people want to introduce another 30 C Functions to TCL's API.

How about this.

We add to interp alias a switch -trailing which adds trailing args to the aliased command. Then lassign becomes:

interp alias -trailing {{}} {} lassign {} foreach

I know, too radical for the TCT, like TIP #57, it actually solves the problem simply without a lot of fuss.

BTW, If this is incompatible with the byte-code compiler, then it just adds to my argument that the BC should not be there.

FW: You don't like the bytecoding? What's so bad about it that's worth sacrificing the 10x performance advantage?

PWQWhen changes are proposed, a lot of them are hard to do because implementing the change requires a major change to the byte-code compiler. My argument is that the BC should not influence changes to either the core or syntax (as in argument expansion)

And yes I would rather TCL be 10x as slow, but have the features I want.

DKF: The reason why lassign is preferred is that it doesn't just handle the use-case that the foreach-idiom handles, but also does something sensible when the number of values in the list doesn't match up with the number of variables to assign to. That is something that the version based on foreach cannot possibly handle.

PWQThis seems to me that you want to add an error trap if they are not the same, Big brother watching out for the dumb programmer, Is this of real benefit.

OTOH, the -trailing option to interp alias is an interesting idea, though in the specific case you're looking at it would be better to do this (so that the effects are more predictable when the number of values exceeds the number of variables):

interp alias -trailing break {} lassign {} foreach

I still prefer the TclX version of lassign though, as it makes the result of the command be a list of those values which were not assigned, which can be extremely useful indeed. One use might be a shift-analog, with the following putting the first three arguments into the arg array and setting argv to those arguments that are left (if any):

set argv [lassign arg(1) arg(2) arg(3) $argv]

Doing such things with foreach is not really that practical (and doubly so when you start to deal with lassigning the results of a command-substitution...)

rmax: That's a nice feature of lassign I didn't notice before. It reminds me of Prolog where the only way to access a list is to take a finite number of elements from the head and assign the tail to another variable.

A practical example for this feature is replacing all but the first of multiple files with identical content by links to the first one. When I have a list with the names of such a set of files, I currently do it this way: