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> 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. >> >
