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

Add map/filter/reduce/range/all/any to avoid accidental bugs in for loops #4596

Closed
vietlq opened this issue Jul 27, 2018 · 5 comments
Closed
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. language design :rage4: Any changes to the language, e.g. new features stale The issue/PR was marked as stale because it has been open for too long.

Comments

@vietlq
Copy link

vietlq commented Jul 27, 2018

The for loops are too verbose and any user can make mistake when increasing/decreasing counters: makoto/blockparty#175

It would be much better to have map/filter/reduce/range/all/any like in Python so people can iterate and apply input in consistent and uniform way that is safe and easy to read.

You may refer to all built-in Python functions here:

https://docs.python.org/2/library/functions.html

@chriseth
Copy link
Contributor

chriseth commented Aug 3, 2018

While this is a good idea, most of the operations that could benefit from that are rather expensive so it is questionable whether such things would be used much, but as I said, still nice to have.

This probably requires #911 and perhaps even #869 to be really useful.

@chriseth chriseth added the language design :rage4: Any changes to the language, e.g. new features label Aug 3, 2018
@leonardoalt
Copy link
Member

I don't think it'd need #869, unless it supports more than arrays., but I think it needs #911 with capturing

@axic
Copy link
Member

axic commented Apr 27, 2020

We discussed as part of https://twitter.com/nomorebear/status/1254000358361186306, range based loops would have avoided some mistakes. (But also unit testing would avoid them too)

@Marenz
Copy link
Contributor

Marenz commented Aug 11, 2020

I am absolutely in favor of range-based loops at the very least.

@NunoFilipeSantos NunoFilipeSantos added the stale The issue/PR was marked as stale because it has been open for too long. label Nov 25, 2022
@github-actions
Copy link

Hi everyone! This issue has been closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

@github-actions github-actions bot added the closed due inactivity The issue/PR was automatically closed due to inactivity. label Jan 31, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. language design :rage4: Any changes to the language, e.g. new features stale The issue/PR was marked as stale because it has been open for too long.
Projects
None yet
Development

No branches or pull requests

6 participants