Inconsistent names between List and Map methods

[jabraham17]

In #21395, we decided to remove the various get* methods on map (getReference(), getBorrowed() and getValue()). These were added to avoid accidentally transferring ownership of classes, but in #21395 the decision was made to have a single get()/this() method that just was carefully implemented to work with owned classes.

However, in making this decision, list seems to have been overlooked. list has a getValue() and getBorrowed() (as well as a this()), instead of a single get()/this() like map. While there doesn't seem to be anything inherently wrong with the implementation, the asymmetry of the names is unfortunate and potentially confusing for users.

I propose making similar updates to list, where getValue() and getBorrowed() are replaced with a single get. However, this is a breaking change and will need to be handled accordingly.

[mppf]

Can the new get() be added as a non-breaking change?

[lydia-duncan]

I think so, but we will also want to update this() for consistency. A get() update could be staged independent of that

[jabraham17]

Perhaps something important to note is that map.get takes two arguments, a key and a sentinel value. It either returns the value of the key, or the sentinel if the map doesn't contain the key. The map.this accessor may throw a KeyNotFoundError error if the key isn't in the map, or add it and default initialize the value (if the value type is default initializeable).

This is very different semantics from what a list.get method would look like, where accessing an invalid index should halt.

I did not fully internalize this when opening this issue, and would adjust my suggestion slightly to say "lets just deprecate and remove 'getValue' and 'getBorrowed'". Which is the breaking part of this change :)