Strings passed as references if accessed like an array

DEF EXAMPLE ARG$
ARG$[0]="R"
END

STRING$="TEST"
EXAMPLE STRING$
?STRING$
REST

EDIT: All strings are passed as references. Have fun. (You can still use the STRING$=STRING$+"" (or STRING$*1) trick to get around this)

Don't you mean "Strings passed as references"... and stop there? Try INC ARG$,"ING"

You can use PUSH and POP on strings as well so I think strings just act like arrays in SmileBASIC. I can see where there might be a problem but this also sounds kinda useful if you ask me. The real problem is that there is no almost no type checking with DEF, which means you can put a string into array parameter or an array into a string parameter.

I don't really see the lack of type checking to be a problem, since it would just cause an unnecessary error. I suppose it could catch a few typos, but it would also break many programs where people have tried to use the minimum amount of characters or something.

If you were to write an DEF that expected an array as a parameter, why would you ever want a string to be passed in? It would just cause an error somewhere in the DEF. That's why there should some type checking with DEF functions. If you specify two strings for the coordinates in a GPSET command, it throws a type mismatch error because GPSET can't work with two strings. That's what should happen with DEF in my opinion. You define the parameters and a call to that function simply won't work unless the arguments match the parameter types.

What about arrays and string arrays how is DEF EXAMPLE ARRAY$ different from DEF EXAMPLE STRING$ or DEF EXAMPLE NUMBER different from DEF EXAMPLE ARRAY and what if you wanted to accept multiple variable types? like DEF CPRINT COLOR%,VARIABLE COLOR COLOR% PRINT VARIABLE END

Strings behave as linear arrays when used in such contexts so this is generally normal behavior. HOWEVER, I've noticed that strings are by-reference when accessed as arrays (this includes stack instructions PUSH etc.) and by-value when otherwise. At least, this appears to be the case to me.

DEF TEST I$
 I$="A"
END

VAR A$="B"
TEST A$
?A$

A$ isn't mutated at all. It's still "B". And yet:

DEF TEST I$
 I$[0]="A"
END

VAR A$="B"
TEST A$
?A$

A$ becomes "A" this time. This behavior is inconsistent and the only reason I can think of why is that string operators instantiate a new string in the heap (immutable strings like basically everything else) and array operations manipulate the memory in-place. In the first case I$ becomes a local reference which is destroyed when the scope exits.

It's not inconsistent, once you take in all the implications of a string variable containing a reference to a string value. Imagine you didn't use a parameter, instead you assumed that the incoming string was always in the global variable A$. Then,

DEF TEST I$

becomes

DEF TEST
VAR I$
I$=A$

Now, I$ contains a reference to the same thing A$ refers to. If you manipulate the thing referred to by I$, then you manipulate the thing referred to by A$, because they refer to the same thing. If you make a new string, and its reference is put into I$... you're not changing the fact that A$ refers to what it refers to.