-
Notifications
You must be signed in to change notification settings - Fork 21
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
Inconsistent copyToArray
semantics between IterableOnceOps
and Vector
(and some other collections).
#12948
Comments
@scala/collections |
If "my collections" are a public repo, could you link? I'd be interested in at least following along to appreciate the use cases. |
I think the most consistent way to handle this, given the behavior of other slice-of-array type of operations, is that mis-indexing into arrays throws an exception, if there's any mis-indexing to do. So if you index outside of the array, and you copy anything at all, you get an exception. If you copy nothing, you're fine. So |
I can never tell if Ichoran gives the simplest possible implementation or specification or both, but I agree. So this is just an implementation bug. The Scaladoc is clear that I sympathize with OP about "always check inputs and fail early", but I also agree with Ichoran that if we're paying for index checks for array access anyway, we should just rely on it. The other argument, about forgiveness in API, is more design philosophy. |
Currently, |
#11048 on the policy of not throwing on no work. |
Thanks for the report and the solution. The PR includes the zero-length destination case. Let me know if there's more. |
Reproduction steps
Scala version: 2.13.12
I made another attempt to bring semantics of my collections exactly in line with the standard library and failed miserably.
I hinted at it #12795, but it gets worse.
Problem
Coincidentally,
yields the same result:
I know one probably has to be autistic to be bothered by it enough to fix it, given limited resources, but is there an official policy of what should happen in both of these scenarios that I can adopt?
``
<soapbox>
These are exactly consequences of the philosophy of deriving API semantics from the simplest possible implementation, rather than the simplest possible specification, as defended in one of my past bugs``.I don't like that negative start index is accepted if the amount to copy is zero, but at least collections using `IterableOnce.elemsToCopyToArray` are somewhat consistent in it. I champion 'always reject negative index' cause in large part because it guards the rest of the code from an underflow.
The text was updated successfully, but these errors were encountered: