Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Update proposal #14
Update proposal #14
Changes from 1 commit
e1a47ee
64219d6
e5d650f
feb2cef
440a0f6
121bd8c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the previous version of this function's spec would also have trapped when the array is null: implicitly as part of the
array.length
load.I'm a little concerned that specifying a specific order of checks/traps might become annoying in the future. For now it's probably fine, but it would sure be unfortunate if N years from now some engine couldn't build the fancy optimization they just thought of because it would observably reorder, say, bounds check and null check traps compared to the previous version of that engine and/or other established engines. Maybe there's just no way to categorically avoid that risk when an operation needs to check more than one thing...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that doing the upfront bounds check would allow for the most flexibility in implementation by making sure any re-ordering of the loop wouldn't need to preserve the proper access order. But I'm open to filing an issue to discuss this more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think checking for
start <= end
(i.e. taking thereturn ""
path whenstart > end
) was useful, let's keep that.(I also didn't mean to express strong opposition to what you had here before. If you'd like to return
""
forend > string.length
, I'm fine with that. I was just pointing out that handling thestart < string.length < end
case by cappingend
is rather simple, if we want to allow it.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reverted the change.