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

[BUG] Changed behavior to scope of iterator in for loop breaks compatibility with Python and acts unintuitive #331

Open
gryznar opened this issue Jun 6, 2023 · 3 comments
Labels
bug Something isn't working mojo Issues that are related to mojo mojo-repo Tag all issues with this label

Comments

@gryznar
Copy link
Contributor

gryznar commented Jun 6, 2023

Bug description

Let consider some basic example:

var i: Int # I want to declare type of "i" explicitly. Intuition also says, that this var will be mutated with every iteration
for i in range(10): 
    pass
print('done at:', i, 'iteration')

What we expect to get? Well, that the value of i will be 9. Actual behavior is:
"done at: 9425703 iteration"

I am aware that it was intentional change to allow:

for i in range(10): pass
for i in range(10): pass

but current behavior is much more unintuitive than previous (in Python analogical code will give 9) and prevents to be explicit about specifying type of this iterator variable. I don't know if it is currently possible to specify type of "i" inside loop definition, but if it is not possible, specifying in outer scope is much more reasonable in static-like languages than not specifying it at all.

One more thing to consider: performance. If keeping scope of iterator variable only to loop gives real benefits in terms of performance it might be reasonable to keep it as it is. If it is not a case, accessing variable from outer scope is much more welcome, in terms of intuition, practical use cases and compatibility.

Edit: yet another thing to add here: lack of consistency.

var s: Int
var i: Int

for i in range(3):
    s= i * 2

In this example variable s will be mutated, variable i not.

So it seems to me, that for keeping compatibility, intuitive behavior and simply usage, variables in function scope should be visible outside, I hope that it won't hurt performance!

@gryznar gryznar added the bug Something isn't working label Jun 6, 2023
@Mogball
Copy link
Collaborator

Mogball commented Jun 6, 2023

This was noted as a known "sharp edge" in the sharp edges/roadmap document. The behaviour here is definitely subject to change, and what you suggested could make sense, but require the declaration of the iteration variable seems not so great. Maybe syntax like for var i in range(3) but I don't have an opinion on the syntax for that.

@Mogball Mogball changed the title [BUG]: Changed behavior to scope of iterator in for loop breaks compatibility with Python and acts unintuitive [BUG] Changed behavior to scope of iterator in for loop breaks compatibility with Python and acts unintuitive Jun 6, 2023
@gryznar
Copy link
Contributor Author

gryznar commented Jun 6, 2023 via email

@ematejska ematejska added the mojo Issues that are related to mojo label Sep 7, 2023
@gryznar
Copy link
Contributor Author

gryznar commented Oct 23, 2023

var total = 10
var i: Int

for i in range(total):
    ...
var i: Int
var total: Int

for i in range(total:=10):
    ...

@Mogball How about sth like that? IMHO there is no sense to declare type of i inside a loop. Even in C, this is valid:

int i;

for (i=0; I < 5 ; i++){}

@ematejska ematejska added the mojo-repo Tag all issues with this label label Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working mojo Issues that are related to mojo mojo-repo Tag all issues with this label
Projects
None yet
Development

No branches or pull requests

3 participants