In http://lang.lucee.org/t/syntax-for-ordered-struct-literals/213 and the previous Google Group thread, a front runner syntax emerged for declaring that you wish to use an “ordered” (or “linked”) struct when creating a struct literal. The following two syntaxes would be equivalent:
I think that the proposed construct should not allow for whitespace between the { and [ at the open, nor the ] and } at close, so that the construct is the consecutive sequence of {[ and ]}, just like the operators == and !=
Any good reason to enforce this rule? I think to have a rule, there needs to be a sound reason.
Is this to make parsing the source code easier, and would it be a problem if whitespace was allowed? I’m not discounting that as a rationale, just wondering if that’s the basis for it?
no. it’s for better readability. when you see the curly braces followed immediately by a bracket then you know exactly what it is. if whitespace is allowed then the curly brace might be on one line and the bracket on another – making it much harder to tell what type of data structure that is.
Right. I personally happen to agree with you as far as clarity goes in regards to a coding standard, but those sort of decisions / positions do not belong in the language itself.
But there you go: we have both expressed a position now. Let’s see what other people have to say.
What I like - the mix of struct and array notation is immediately instructive to people reading the syntax for the first time (Array = ordered, struct = struct). Concerns - Mix of [ and { could lead to confusion, especially when not layed out well Mitigating ideas - As @21Solutions suggested, forcing zero whitespace between { and [, and ] and } should mitigate the confusion of array and struct syntaxes and force treating the character combinations more like a single character. Gut - I’m a little on the fence, but siding towards supporting its implementation
I disagree. just like you have other operators that are made of other characters without whitespace, like !=, ==, and ===, you can set {[ and ]} to be the operator.
It’s possibly worth noting that by mandating zero whitespace you remove the overhead of stripping the whitespace when the language interpreter is deciding whether the { is the opening tag of a a “default” struct, or whether it’s the opening tag of {[.
I think Igal made a reasonable point before with his example of other operands. Sorry… saw it at the time and meant to reply but never got around to it.
On this one (Simon’s point) though: it’s a compile time thing, so doesn’t really matter in the bigger scheme of things. Code only compiles once for the lifetime of the app, after all. This sort of thing in and of itself ought not be an economy one concerns one’s self with.
Anyway, this is just minutiae. It’s a good idea: that’s the main thing.