Array container fixes #716
Conversation
Tighter enforcement. Indented ///Ditto Direct call to _outer._data._payload Unit tests for both
Grammar fix in implementation documentation
Several deprecated items were listed for removal in August, but it's looking likely that 2.060 will come out in August, and I'd prefer not to have them removed for 2.060 given how many items are already in the changelog, and they're already deprecated, so it'll only affect people compiling with -d either way. So, I'm changing the ddoc comments to say September instead of August. They'll be removed in 2.061.
Tighter enforcement. Indented ///Ditto Direct call to _outer._data._payload Unit tests for both
|
botched merge |
|
You can just repair the branch locally (if you'd like to start over, just delete it and create one with the same name), and then push it using Bugzilla tickets are usually closed by the one doing the merge. |
|
I'm terribly sorry. I was trying to save the branch by doing a merge + squash, but I totally failed it. I decided the last course of action possible was to delete the branch and recreate. I'm sorry about the trail of broken pull requests :/ Delete and recreate the branch with the same name was exactly what I did, but didn't realize that if I did it completely locally, I could save the branch (rather than dupe it). Thankyou for your advice. This is the last time I botch a pull. |
|
No need to be sorry, what you did is not exactly wrong, the other way is just more elegant. ;) |
This commit first fixes issues 8332 and 8333:
http://d.puremagic.com/issues/show_bug.cgi?id=8332
http://d.puremagic.com/issues/show_bug.cgi?id=8333
Basically, Array and Array.Range did not implement opIndexUnary. Also, Array.Range.opIndexOpAssign was not compiling due to a typo type bug.
These issues were opened by me, and are not assigned to anyone. I'm not sure about the protocol regarding bugs... Should (can) I assign them to myself? Will someone else (andralex?) close them?
I also added:
_Documentation of invariants/enforcements of Array.Range for future developers.
*Stricter enforcement in Array.Range: Quite a few illegal operations were executed without complaining.
*Direct call to _outer._data._payload in Array.Range:
*_avoids double checking of "_data.RefCounted.isInitialized", which should already be validated by either of "!empty" or "i < _b && _b <= length".
*_Also avoids double check of "empty etc..."
*_Allows more efficient implementations using move(value, target)
*"Correct" indentation of "Ditto" documentation
*Unit tests.