P.S. Besides, a decent implementation of size-extend in case of too big gaps should automatically switch the underlying implementation to a sparse list, of which the programmer does not need to be expliticly aware :)
P.P.S. I've tried array.withDefault and found it is not supported, and one is forced to uglies like “(arr as List).withDefault...”. That's one thing I would add; could hardly break any current code I'd say? Or do I overlook something of importance? > On 6. 2. 2025, at 20:37, o...@ocs.cz wrote: > > Well but again, making List throw in future would break a vast codebase, > which is a big no-no. > > Far as I know, there's no auto-extending unless you explicitly ask for that > by withDefault. > > Thanks and all the best, > OC > >> On 6. 2. 2025, at 20:16, MG <mg...@arscreat.com <mailto:mg...@arscreat.com>> >> wrote: >> >> My take on this for list-like structures: >> Since the potential for hard to track errors is so high - and for least >> surprise - default behavior should always be to throw on out-of-bounds >> access. >> Returning a default value for out of bound access can be very conventient, >> but should be made explicit; we e.g. use the following naming convention in >> our code in this case: >> getWithDefault(index, defaultVal) >> We don't need that, but a more general version might be: >> getWithDefault(index, defaultValClosure) >> getWithNullDefault(index) >> Automatically extending the size seems to be the worst option, given that >> one too large index access could easily exhaust a computer's main memory (-: >> Cheers, >> mg >> >> On 06/02/2025 17:27, Milles, Eric (TR Technology) via dev wrote: >>> Is there any explicit statement about how indexing beyond the end of a >>> collection should work? Does it extend the collection or just return null. >>> Does a withDefault collection do something different? >>> >>> In general, arrays and collections should work the same, so the statement >>> in the working with arrays section is a good one. In the matter of >>> indexing beyond the end of the array or collection, what is the shared >>> behavior supposed to be: >>> >>> return default value for type — aka null for reference and 0/false for >>> primitives >>> throw out-of-bounds exception >>> something else? >>> >>> From: OCsite <o...@ocs.cz> <mailto:o...@ocs.cz> >>> Sent: Thursday, February 6, 2025 10:11 AM >>> To: dev@groovy.apache.org <mailto:dev@groovy.apache.org> >>> <dev@groovy.apache.org> <mailto:dev@groovy.apache.org> >>> Subject: [EXT] Re: a bug or my fault? >>> >>> External Email: Use caution with links and attachments. >>> >>> The overall intention is that whether you are using an array or a >>> collection, the code for working with the aggregate remains the same >>> <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>. >>> >>> In this particular case alas that good and noble intention does not quite >>> work, and I wonder whether that is intentional (forgive the pun) or a >>> mistake to be fixed in future, when there's nothing more pressing to do. >>> >>> On 6. 2. 2025, at 13:30, Søren Berg Glasius <soe...@glasius.dk> >>> <mailto:soe...@glasius.dk> wrote: >>> >>> You assign 'b' as an Array, and arrays works differently than lists. Arrays >>> are bound to their length, so 'a[2]' should report out of bounds as it is >>> not 3 elements long, whereas a list b[2] would report null >>> >>> IMO it's working as intended. >>> >>> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <o...@ocs.cz >>> <mailto:o...@ocs.cz>>: >>> Hi there, >>> >>> is this inconsistence intentional and the proper Groovy behaviour, or is >>> that a bug and should I add a jira ticket? >>> >>> Thanks! >>> >>> === >>> groovy:000> a=[1,2] >>> ===> [1, 2] >>> groovy:000> b=a as Object[] >>> ===> [1, 2] >>> groovy:000> a[2] >>> ===> null >>> groovy:000> b[2] >>> ERROR java.lang.ArrayIndexOutOfBoundsException: >>> Index 2 out of bounds for length 2 >>> groovy:000> >>> === >>> >>> >>> -- >>> >>> Med venlig hilsen, >>> Søren Berg Glasius >>> >>> Hedevej 1, Gl. Rye, 8680 Ry >>> Mobile: +45 40 44 91 88 >>> --- Press ESC once to quit - twice to save the changes. >>> >> >
