Revisit strictness of Access module

[amandasposito]

This PR aims to solve the issue #6515, that opened a discussion about lifting the restriction for the Access module, so it could interact with non-tuple lists.

I removed the call to the Keyword.get_and_update and Keyword.pop functions and implemented a solution closer to the Keyword private functions, just handling the new scenario for non-tuple lists.

The reason why I didn't implement a partial solution, using both Access and Keyword, was because it could cause a performance issue.

[umamaistempo]

Since this does not requires the list to be a keyword anymore, i'd say to add tests using binary keys 😁

eg:

assert [{"foo", 1}, {"bar", 2}]["foo"] == 1

[ericmj]

Thanks for the PR. I believe we are still discussing if we are going to support non strict keywords and in what way we are going to do it so we will hold off on merging this PR until we have a decision.

[ericmj]

Since this does not requires the list to be a keyword anymore, i'd say to add tests using binary keys

We are not planning to extend keywords in this way. You should use maps for this instead.

[josevalim]

We are not planning to extend keywords in this way. You should use maps for this instead.

It is still true though that this is no longer a keyword so there is no reason to also not support binaries. I am not saying we should, but it would be a valid direction.

[josevalim]

Hi @amandasposito!

I am so sorry but we have decided to not move this forward and keep Access semantically close to Keyword instead of introducing a third construct.

Apologies for the long time it took us to address this. ❤️