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

expire_func unhelpful for containers with multiple indices #461

Open
vpax opened this issue Jul 10, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@vpax
Copy link
Contributor

commented Jul 10, 2019

The current type-checking requires that &expire_func's take exactly two arguments, the first being the container itself, and the second being the index into the container corresponding to the expiring element. This restriction means that you can't use &expire_func's in any sort of flexible way for containers with multiple indices.

A work-around is to change the container to be indexed by a record instead (ugh).

@ckreibich

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2019

I think there's an asymmetry here between how we can spell out a tuple of values vs. a tuple of types. For the former, we can use the [...]-notation in for-loops over key/val pairs, or keys that are tuples (see discussion here). That is, we can say

for ([i, j] in something)

when that something is e.g. a set[count, count], but we don't have a similarly convenient way of saying that an argument to a function is a [count, count].

If the solution here is that we unpack the tuple into multiple arguments to the &expire_func, then that's in a way making things more asymmetric. Seems it would be nicer to make such tuples explicit, so they can be passed in as a single argument. I'm not immediately sure what that should look like. Perhaps something like function foo(..., val: [count, count]), with vector-style numeric indexing to get the individual vals.

@vpax

This comment has been minimized.

Copy link
Contributor Author

commented Jul 10, 2019

@ckreibich nice thought! Not sure though how much work it might wind up being, to do this coherently.

@rsmmr

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

Might be easier to implement unpacking outside of function arguments, like through locals like this:

   local [x, y] = val;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.