On Tuesday, 1 September 2020 at 18:20:17 UTC, Jesse Phillips
wrote:
This is going to be a hard one for me to argue but I'm going to
give it a try.
Today if you attempt to access a key from an associative array
(AA) that does not exist inside the array, a RangeError is
thrown. This is similar to when an array is accessed outside
the bounds.
[...]
I don't have an issue with the normal array RangeError, there
is a clear means for claiming your access is a programming bug.
However associative arrays tend to have both the key and value
as "input."
[...]
Is it recoverable? I would say yes. We aren't actually trying
to access memory outside the application ownership, we haven't
put the system state into a critical situation (out of memory).
And a higher portion of the code could easily decide to take a
different path due to the failure of its call.
Any time you have an operation that can only succeed if some
precondition is met, there are two possible ways you can
implement it:
1. Make it the caller's responsibility to check the precondition.
2. Make it the function's responsibility to check the
precondition.
If you have version #1, you can always use it to implement
version #2, but the converse is not true. So, while you would
ideally provide both versions and let the user choose the one
they prefer, you should always *at least* provide version #1.
In this case, for D's associative arrays, the [] operator is
version #1. You could make a reasonable case that the [] operator
should have been reserved for version #2, and version #1 should
have been named something else, but at this point, it's not worth
breaking backwards compatibility to change it.
