ltzmaxwell
ltzmaxwell
for loops maintain the same block on iteration, which is referenced in any closures generated within
I have a fix in #1585, it works like this: ```go package main func main() { var fns []func() for _, v := range []int{1, 2, 3} { x :=...
for loops maintain the same block on iteration, which is referenced in any closures generated within
> Putting this here for reference. Here are the attempts to fix this that have not been merged: #1768, #1585, [deelawn#3](https://github.com/deelawn/gno/pull/3) > > This is the one currently in progress:...
for loops maintain the same block on iteration, which is referenced in any closures generated within
> @ltzmaxwell do we close #1818 or do you want to iterate on it? it's actually ready for review. thanks.
for loops maintain the same block on iteration, which is referenced in any closures generated within
close this as solved by #2429. Go1.22 loopvar is not supported at the moment, defer for future optimization. cc: @moul @thehowl @jaekwon for visibility.
> We can add this, though we should consider that IIRC this feature was added after go 1.18, so I would say it's somewhat less of a priority, like `min`...
> Can we make GetPackage call GetObjectSafe, at this point? > đź‘Ť , see [f76bdb2](https://github.com/gnolang/gno/pull/4376/commits/f76bdb2cc11c6d0541aaad5f94e39d8e131a0536) > I'm worried if this might encourage misuse of `GetObject` to get packages more generally;...
>I'm worried if this might encourage misuse of GetObject to get packages more generally; maybe one small step against this is to unexport ObjectIDFromPkgPath? I think the reason we didn’t...
the cause for this is when conducting test with native_libs, stdlibs are loaded as well. this. The test store is kinda polluted that std libs will reference the corresponding native...
> This is not reviewable. There is too many dependencies on other issues and prs. that it is. hopefully I will make #1426 available next week.
Hi @thehowl , this one is good to review too.