You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The subscript expression has the following builtin behaviors before delegating to overloads of []:
generic type invocation
generic routine invocation
including symchoices, probably should be left as (at (choice ...) ...)
array indexing (in overload)
openarray/uncheckedarray/varargs indexing
cstring indexing (in overload)
string/seq indexing - done for seq/string implementations
tuple indexing
We could maybe move the indexing operations to overloads rather than handling them in the compiler, but this has some incompatibilities as outlined here, namely:
which might not work as expected any time soon, so it might be better to keep it builtin.
In any case, it would be nice to not have the super-overload of ArrGet /ArrPut in the old Nim that needs constant special casing. Hopefully we won't need it.
We also might need different tags (magics) than (at) for different behaviors of the operator, especially given (at) is the tag for parsed, unsemchecked subscripts. Probably enough to separate indexing between array-likes and seq-likes but idk.
The text was updated successfully, but these errors were encountered:
From the ideas in #194
The subscript expression has the following builtin behaviors before delegating to overloads of
[]
:(at (choice ...) ...)
We could maybe move the indexing operations to overloads rather than handling them in the compiler, but this has some incompatibilities as outlined here, namely:
Tuple indexing may need a wacky signature like:
which might not work as expected any time soon, so it might be better to keep it builtin.
In any case, it would be nice to not have the super-overload of
ArrGet
/ArrPut
in the old Nim that needs constant special casing. Hopefully we won't need it.We also might need different tags (magics) than
(at)
for different behaviors of the operator, especially given(at)
is the tag for parsed, unsemchecked subscripts. Probably enough to separate indexing between array-likes and seq-likes but idk.The text was updated successfully, but these errors were encountered: