Skip to content

Conversation

@Hugo-Inmanta
Copy link
Contributor

Description

Add iteration over dict keys in for loops

closes inmanta/std#639

Self Check:

Strike through any lines that are not applicable (~~line~~) then check the box

  • Attached issue to pull request
  • Changelog entry
  • Type annotations are present
  • Code is clear and sufficiently documented
  • No (preventable) type errors (check using make mypy or make mypy-diff)
  • Sufficient test cases (reproduces the bug/tests the requested feature)
  • Correct, in line with design
  • End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
  • If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

if isinstance(value, list):
_iterator = value
elif isinstance(value, dict):
_iterator = value.keys() # type: ignore
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how to type this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you did here, but I don't feel that we should propagate the dicts this deeply. For one thing, dicts aren't always flattenable. While in the DSL we have no nested lists, we can have dicts inside lists. In other words [[1], [2]] is equivalent to [1, 2], but [{"a": "b"}] is not equivalent to {"a": "b"} or to ["a"].

I can imagine it may be difficult to understand the full implications of this, considering that this is quite an advanced method in a codebase you're only partially familiar with. The model below might help illustrate it. When compiled on master, it prints @{'a': 1, 'b': 2}. On your branch, it prints that, preceded with a and b. The fact that it prints both is actually due to the lack of a consistency safeguard in the for loop. The list comprehension does have it. If such a safeguard where there, the compiler would raise an exception instead. Either way, this is clearly not the intention.

d = {"a": 1, "b": 2}
for i in [d]:
    std::print(i)
end

All this said, what would be the appropriate location to handle this? I was going to say For.execute() , which is mostly just a type check, and GradualFor.receive_result. But as I type this I realize that GradualFor.receive_result will also need some way to determine whether it should or should not iterate any dict values it receives. And I don't have an immediate solution for it. I'll get back to this tomorrow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm starting to think that this will be a major hurdle, and that we should go for the plugin after all. We can discuss it tomorrow.

@Hugo-Inmanta Hugo-Inmanta requested a review from sanderr January 12, 2026 15:44
@Hugo-Inmanta
Copy link
Contributor Author

@sanderr Let me know if I missed anything it's been a while since I worked on the DSL

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 this pull request may close these issues.

add dict_keys plugin

3 participants