ID:926627
 
Applies to:
Status: Open

Issue hasn't been assigned a status value.
Even though it's declared as a list with square brackets, you wouldn't be able to tell from looking at the object tree (show all nodes).
The compiler never actually knows L[] is a list at all, that's why you can't directly access the list procs with it, that's the whole reason for defining a list under /list.
But... You can. So it must.
You can use list procs when you just use L[]. This automatically typecasts it as a list object, apparently.

var/mylist[0]
mob/verb/test_list()
mylist.Add("1","2")
world << list2params(mylist)

It does work, so Nadrew...you're wrong about the compiler not knowing it's a list. Intuitively, it should appear on the Object Tree.
In response to Super Saiyan X
I've been using spaces to declare variables and square brackets for lists ever since I discovered I could. I also use the "bounds" variable at compile-time to set bounding boxes.
Yeah...I never use bracket lists. nor the bounds variable, or spaces instead of slashes. Still, yeah, feature supported ++, the compiler DOES recognize them as lists, just they're not in the object tree.
The compiler is *very* loose about brackets. Take the following:

var/myList[0];
var/list/haha;
var/mob/hi[0];


myList is an untyped variable, haha is a /list, and hi is a /mob. What you would expect is:

myList is a /list, haha is a /list, hi gives a compile-time error (Cannot initialize a list here, or somesuch).

I think the better solution would be to remove the square brackets altogether, as they are really a language inconsistency. They are also a bit of an oddity, because in virtually any other language declaring an array with a specific size will not let you expand or shrink that array.

I actually expected the same to be the case here (That if you initialized a list with a fixed size, the size was immutable), but thats not the case after testing it.
In response to Alathon
myList is most definitely a /list variable. Typecasted, declared, initialized. The only problem here is that the object tree doesn't categorize lists as intuitively as possible in all cases.
In response to Kaiochao
Kaiochao wrote:
myList is most definitely a /list variable. Typecasted, declared, initialized. The only problem here is that the object tree doesn't categorize lists as intuitively as possible in all cases.

According to the Dream Maker IDE it is untyped. You know, the thing everyone in this thread is talking about.

The biggest problem here is a huge language inconsistency, for no gain. One that is most likely there as a legacy implementation from when there were no procedures attached to lists at all. And that causes 'interesting' things such as var/mob/hi[0] being a /list, but also being interpreted as a mob at the same time.

As an example, this will silently crash the procedure and not generate any compile-time / runtime errors or warnings:

var/mob/hi[0];
mob/verb/Test() {
world << "[hi.name]";
}
I think the reason why brackets are still in is because of the fact you can directly access them through numbered indexes (depending on what kind of list they are of course). The ones that might show a few issues are associative lists when trying to use numbered index to access square brackets since they can utilize stringed names in square brackets.

Some of the libraries I'm working on utilize square brackets not to initalize, but rather to access the data (using a handy 'for' loop for such a situation) through numbered indexes.
In response to Bandock
Bandock wrote:
I think the reason why brackets are still in is because of the fact you can directly access them through numbered indexes (depending on what kind of list they are of course). The ones that might show a few issues are associative lists when trying to use numbered index to access square brackets since they can utilize stringed names in square brackets.

Some of the libraries I'm working on utilize square brackets not to initalize, but rather to access the data (using a handy 'for' loop for such a situation) through numbered indexes.

True. It still feels like half a solution though - In the current context, a list.Get(idx) proc seems more appropriate.
In response to Alathon
As well as list.Set(idx, value). But why do that when we can use brackets? I like it because it reminds me of JavaScript somewhat.

Also, I'd say that declaring a variable "var mob/L[]" without any kind of error is a bug not related to my issue.
In response to Kaiochao
Kaiochao wrote:
Also, I'd say that declaring a variable "var mob/L[]" without any kind of error is a bug not related to my issue.

It is. It was more to point out that it seems to really have wacky elements surrounding suffix brackets.
I remember Lummox saying something about lists being implemented fairly inconsistently through BYOND about three or four years ago. I've actually encountered some really weird list bugs particularly in the savefile access portions of the engine.
So it's pretty clear that having square brackets at the end of a variable declaration makes the variable a /list type variable regardless of any type written before the variable name.
// these are all equivalent
var stuff[]
var list/stuff
var atom/movable/stuff[]

// and these all contain an empty /list object
var stuff[0]
var stuff[] = new
var stuff[] = list()
var list/stuff = new
var mob/stuff[0]
var mob/stuff[] = new

This feature request is to make the Object tree organize lists declared with square brackets under the list node.

Both my_list and my_other_list should appear at the same level, as children of the list node.

Also, this kind of organization should be considered a bug:
Frankly I have no idea how I'd manage that. The tree is still very arcane.