'''Note:''' This is a renaming of [string append].

This extends the command string to accept a new sub-command '''concat''':

 if {[catch {string concat}]} then {
    rename string STRING_ORIGINAL
    proc string {cmd args} {
        switch -regexp -- $cmd {
            ^con(c(a(t)?)?)?$ {
                uplevel [list join $args {}]
            }
            default {
                if {[catch {
                    set result\
                        [uplevel [list STRING_ORIGINAL $cmd] $args]
                } err]} then {
                    return -code error\
                        [STRING_ORIGINAL map\
                             [list\
                                  STRING_ORIGINAL string\
                                  ", compare, equal,"\
                                  ", compare, concat, equal,"]\
                             $err]
                } else {
                    set result
                }
            }
        }
    }
 }

Test if it does as expected:

 % string concat hully gully
 hullygully
 %

Yeah. Check an original sub-cmd:

 % string match -nocase hully gully
 0
 % 

Works. Great. Now some erraneous situation:

 % string match -nocase hully gully bully
 wrong # args: should be "string match ?-nocase? pattern string"
 % 

The err msg hides the ''STRING_ORIGINAL'' and shows up ''string'' instead. Great again. Now another situation:

 % string what'dya'mean?
 bad option "what'dya'mean?": must be bytelength, compare, concat, equal, (...)
 % 

The err msg shows up all sub-cmds inclusive concat. Yep. That's it. Errp.

----
[AMG]: Why is there no [[string concat]] in the core?  It would be helpful for concatenating strings that are quoted in different ways.  For example:

======
string concat "dict with Sproc-[list $name]" {([list [namespace tail [lindex [info level 0] 0]]])} \{$script\}
======

is quite a bit easier to read (in my opinion) than:

======
"dict with Sproc-[list $name](\[list \[namespace tail \[lindex \[info level 0\] 0\]\]\]) {$script}"
======

[Lars H]: There probably isn't any particular reason. [TclX] provides this as the [cconcat] command. [string concat] is to some extent emulatable by combining [join] and [list], like
 join [list "dict with Sproc-[list $name]" {([list [namespace tail [lindex [info level 0] 0]]])} \{$script\}] ""
or more recently using [apply]
 apply {args {join $args ""} ::} "dict with Sproc-[list $name]" {([list [namespace tail [lindex [info level 0] 0]]])} \{$script\}
so maybe that worked well enough for those with the power to add it. I know I have on occation missed it, though.

----
[LV] Does string concat have functionality different from just using the two strings together?

======
set str1 hully
set str2 gully
set str3 $str1$str2
======

or even using [append]?

======
set str3 hully
append str3 gully
======

[AMG]: As far as I can tell, no.  But it avoids creating temporary variables.

[LV] I only used the variables for illustration. You can do the automatic concatenation in most contexts. The trickiest point would be when mixing a list and a string:
======
set a "[list 1 [list 2 3 4] [list 5 6 [list 7 8 9]]] are the first nine digits"
1 {2 3 4} {5 6 {7 8 9}} are the first nine digits
======
If one of the strings is going to be a list, then you have to make use of [join]. However, otherwise, you can do things like
======
puts "string1String2"
set b "string1[proc2]"
======
and so forth.

======

----
[Stu] 2009-01-26

======
proc strJoin {args} { return [append {} {*}$args] }

set map [namespace ensemble configure string -map]
dict append map join strJoin
namespace ensemble configure string -map $map
======

[AMG]: Hmm, [[[join]]] could also be used.  This way no dummy variable is created.

======
proc strJoin {args} {join $args ""}
======

----
!!!!!!
%| [Category String Processing] |%
!!!!!!