> Does it make sense or even it could be an improvement to the actual "lset" function?
I haven't measured the difference, but I'd consider Tcl's on-board mechanisms first (error codes). This is my take (without proper arg handling, obviously).
proc LSet {args} {
if {[lindex $args 0] eq "-nocomplain"} {
set args [lassign $args withNoComplain]
}
try {
uplevel 1 lset {*}$args
} trap {TCL OPERATION LSET BADINDEX} {msg opts} {
if {![info exists withNoComplain]} {
return -options $opts $msg
}
}
}
- the "-nocomplain" is more what you are after (as used in other places like unset)
- lset provides a proper errorcode (TCL OPERATION LSET BADINDEX) to trap (either using try or catch)
- I agree with Arjen that defaults won't work here (besides, there is no default for [set] either)
- "Does it make sense": [lset] alone is not compelling for me, personally, but there appear to be some inconsistency with handling valid and invalid list ranges between commands (bad index has different failure semantics in lrange than in lset, for example). Arriving at consistency here is more of a priority, IMHO.
Stefan