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

Random.nextInt(int max) could be optional #5362

Closed
DartBot opened this issue Sep 21, 2012 · 3 comments
Closed

Random.nextInt(int max) could be optional #5362

DartBot opened this issue Sep 21, 2012 · 3 comments
Labels
area-library closed-not-planned Closed as we don't intend to take action on the reported issue P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Sep 21, 2012

This issue was originally filed by @financecoding


Mentions default implementation supports a max of ((1<<32) - 1), why not make the parameter optional?

abstract int nextInt([int max]);

 /**
   * Generates a positive random integer uniformly distributed on the range
   * from 0, inclusive, to [max], exclusive.
   *
   * Implementation note: The default implementation supports [max] values
   * between 1 and ((1<<32) - 1) inclusive.
   */
  abstract int nextInt(int max);
https://github.com/dart-lang/bleeding_edge/blob/master/dart/lib/math/random.dart#L28

@iposva-google
Copy link
Contributor

Set owner to @iposva-google.
Added Area-Library, Accepted labels.

@lrhn
Copy link
Member

lrhn commented Aug 19, 2013

Removed Type-Defect label.
Added Type-Enhancement label.

@kevmoo kevmoo added P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug and removed accepted labels Feb 29, 2016
@iposva-google iposva-google removed their assignment May 31, 2016
@lrhn
Copy link
Member

lrhn commented Aug 11, 2017

We don't recommend using random.nextInt(maxInt) unless you actually have a limit of maxInt. That is unlikely to happen a lot in practice.
On the other hand, accidentally omitting an argument would not get caught if the argument was optional.
All in all, the odds of catching mistakes outweighs the odds of actually saving typing by a large margin, so it's probably not an improvement to make the parameter optional.

@lrhn lrhn closed this as completed Aug 11, 2017
@lrhn lrhn added the closed-not-planned Closed as we don't intend to take action on the reported issue label Aug 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-library closed-not-planned Closed as we don't intend to take action on the reported issue P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

4 participants