Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
var/list/L = list("A" = 20, "B" = 21, "C" = 22)

//Something like:
var/A = L.A
var/A = L..A
var/A = L@A
//Compiling to:
var/A = L["A"]

//Same for:
L.A = 2
L..A = 2
L@A = 2
//Compiling to:
L["A"] = 2

This would only work for string keys.
L.A is preferred but the other proposed operators are due to things like .len, and the new 512 method chaining, which might complicate things (could perhaps just not allow .len etc, to be converted?)

Associative lists alrady do something similar when defined:
var/list/L = list(A = 20, B = 21, C = 22)
//Already compiles to:
var/list/L = list("A" = 20, "B" = 21, "C" = 22)

So it feels like it would fit in the language

I feel this would just be a nice piece of sugar, I use assoc lists A LOT and being able to do it quicker would be great.
Because JS does it doesn't mean it's a good idea.

Putting a clear line between list and object is good. Not to mention the hell it would be if Lummox added another property to lists later down the line, and the code begins conflicting.
Doesn't innately make it a bad one either.
No, but this is still a terrible idea nontheless.
It can't work. Lists already have vars that can be accessed via the . operator, so this would only lead to a lot of confusion.

Frankly I'd be more interested in a double-bracket operator to do things like L[L[item]] as L[[item]] instead, although that interest doesn't extend deep enough to actually do it.
I mean, I did propose other operators, but this was expected, it was just a small wishlist item anyway.