Explanation about the use of '@' token

[stefanos82]

In The "type" type you explain that

In the middle of statements the @ token is required to precede a type expression. This token signals to the compiler that a type expression comes after it.

With your latest commit(s), you show the new inferred methodology for an array: local c: auto = (@[]integer){1,2,3,4}; I really like it.

What got me wondered though is why we need to have a typecast method and not something like local c: auto = @[]integer{1,2,3,4}?

[edubart]

What got me wondered though is why we need to have a typecast method and not something like local c: auto = @[]integer{1,2,3,4}?

Because the syntax would be ambiguous for other type expressions, suppose (@[4]integer){1,2,3,4} could be simplified to @[4]integer{1,2,3,4}, then (@integer)(1) would be also simplified to @integer(1) as a side effect, but now integer(1) is ambiguous, is this a type initialization or a generic type? This is an example, there are other syntax problems in allowing that, for both the parser and the reader. Type expressions in the middle of usual expressions must be surrounded by (@ ) because dropping these tokens make many cases ambiguous and confusing. This is because type expression follow different rules while share same tokens as normal expressions.

[stefanos82]

Because the syntax would be ambiguous for other type expressions, suppose (@[4]integer){1,2,3,4} could be simplified to @[4]integer{1,2,3,4}, then (@integer)(1) would be also simplified to @integer(1) as a side effect, but now integer(1) is ambiguous, is this a type initialization or a generic type?

What I have had in mind is the following concept:

local a: auto = @[]integer{1,2,3,4}
print(@a[0], @a[1])

I didn't know it would affect the whole behavior like that 😞