-
Notifications
You must be signed in to change notification settings - Fork 164
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
Should we remove brackets from range syntax? #445
Comments
I think it would be nice to keep them, not based on anything but my personal opinion |
It appears that most languages (Rust, Swift, Ruby) use a notation without brackets. Haskell seems a bit like the odd man out. |
+1, there’s no need for them |
+1 from me too...
fre. 22. dec. 2017 kl. 01.59 skrev Charlotte Tortorella <
notifications@github.com>:
… +1, there’s no need for them
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#445 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABHRu1-PpkY4JHRGptYQ1E_-oBVajmovks5tCv7lgaJpZM4RJeUj>
.
|
I will remove the brackets once the block is over, so no student projects run into a sudden syntax change. |
The block is over; change incoming. |
athas
added a commit
that referenced
this issue
Jan 28, 2018
athas
added a commit
that referenced
this issue
Jan 28, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have realised that there is no syntactic reason to require brackets around a range literal:
We might as well write it as:
There is no ambiguity. Swift does it this way. Should we, too? It is mostly a question of whether the brackets make it clear that an array is being produced. Due to the low operator priority of
...
, many uses will still require parentheses:But others will not:
By a quick search in the benchmarks repository, we have 21 uses of range literals, and 11 of these will not require parentheses.
The text was updated successfully, but these errors were encountered: