Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

builtin subscripts & required magics for indexing #269

Closed
5 of 8 tasks
metagn opened this issue Dec 24, 2024 · 0 comments · Fixed by #348
Closed
5 of 8 tasks

builtin subscripts & required magics for indexing #269

metagn opened this issue Dec 24, 2024 · 0 comments · Fixed by #348
Assignees

Comments

@metagn
Copy link
Collaborator

metagn commented Dec 24, 2024

From the ideas in #194

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:

  • they accept arbitrary pointer dereferences,
  • any integer type is allowed for the index.

Tuple indexing may need a wacky signature like:

proc `[]`[T: tuple](tup: T; index: static int): typed {.magic: TupleIndex.}

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant