[CyberDildonics]

I think that is a giant design mistake since you are pushing the discovery of an error to some place else in the program, potentially very far from where the error occurred.

[luckydude]

Without providing an example of how to do it better, I'm not sure I see your point. Yeah, I see the problem you point out.

Consider

char *p = 0;

some complicated code that should have set p but didn't...

char c = *p; // SEGV

So do you have a way to push that error all the way back to wherever you think it should be pushed?

[CyberDildonics]

The person you replied to asked what the behavior was when you access an offset of an array that doesn't exist and you are giving me an example of dereferencing a null pointer.

The array access should error out on the line that it happens.

The dereference could print a line of the last assignment, but this isn't what was being talked about.

[luckydude]

I don't see the array access as any different than a null pointer dereference, in both cases you are asking for something that isn't there.

In Tcl, stuff just gets auto expanded on assignment and returns "" (I think) on dereference. We chose to return undef. I'm not sure what the problem is.

[CyberDildonics]

I explained the problem already (the error does not show up where it actually happens).

I also explained a huge difference between the two already (you know how large an array is and can detect an out of bounds access when it happens).

[luckydude]

You seem bound and determined to not hear that tcl auto expands arrays as needed. There are no bounds. So there is no error to catch.

We just thought it would be clever to return undef if you were out of bounds, which tcl code would see as "" which is what you'd get in tcl. But Little code could actually tell you are past the end.

In my mind, which many have argued isn't the best, it's a reasonable design.

You keep trying to push backwards to a design point where arrays are fixed in size at declaration and that is not how tcl (or Little) works.

[zimpenfish]

> There are no bounds. > clever to return undef if you were out of bounds

You can see how this is getting confusing.

> So there is no error to catch.

Thing is, you're already catching the error because "Little code could actually tell you are past the end" and "return undef if you were out of bounds" - you're just smooshing the error under the carpet into an `undef` return rather than bombing out with an OOB error (which is what I think GP was actually after.)

(If Little returns `undef` for OOB and `""` for in-bounds-not-set, you can detect the OOB access error in your own code but that hasn't been made clear, I don't think?)