 Author:         Donal K. Fellows <dkf@users.sf.net>
 State:          Final
 Type:           Project
 Tcl-Version:    9.1
 Vote:           Done
 Created:        08-Sep-2025
 Keywords:       Tcl, safe interpreter
 Tcl-Branch:     tip728-interp-set
 Votes-For:      HO, DKF, APN, SL, AK, MC
 Votes-Against:  none
 Votes-Present:  none

Abstract

This TIP proposes adding a mechanism for access to Tcl_GetVar() and Tcl_SetVar() in a child interpreter.

Rationale

Sometimes, code needs to read and/or write variables in a child interpreter. This is particularly the case when setting up a safe interpreter, but it occurs in many places. Current practice is to use $child eval set to do this, but this suffers from the risk that the child interpreter may have overridden the definition of set, and also requires some care with word boundaries when setting. Rather than continue to struggle on with this, we ought to make things easier.

Specification

I propose adding two closely subcommands (really just the same thing with two ways to access it):

interp set child varName ?value?
child set varName ?value?

These both essentially take the name of a child interpreter, the name of a variable within the interpreter (to be resolved in the current namespace context of that interpreter, similarly to how interp eval works for commands), and optionally a value to set. Parallel to how the standard set command works, if the value is given, the variable in the child will be set (with any applicable traces being called in the child context) and the new value of the variable will be returned. If value is not provided, the contents of variable in child (after trace processing) will be returned.

Note that there is no concatenation of arguments, and that redefining set in child will have no impact on the behaviour of the subcommands specified here.

Compatibility

The interp set command was previously a simple syntax error (i.e., it's a new subcommand), and introduces very little new code. There's no concerns with migrating representations across interpreters that didn't already exist; interp eval (which this replaces in some specific cases) isn't careful anyway.

Theoretically there should be an interp unset, but I've yet to see any actual use cases for that outside of one of Tcl's own tests.

Reference Implementation

See the tip728-interp-set branch.

Copyright