Change Dict field names to _keys and _vals

[CameronBieganek]

To avoid new users accidentally accessing the internals of a dictionary via d.keys or d.vals (e.g., if they're coming from an OOP language), it's probably a good idea to change the names of those fields to _keys and _vals.

Inspired by this question on Discourse:
https://discourse.julialang.org/t/dictionary-showing-invalid-keys/96422

[KristofferC]

This will break a lot of code out there. Does not seem worth the churn.

[oscardssmith]

do you have an example of someone using this outside of base?

[jishnub]

This sounds like something a linter might warn against

[petvana]

The number of packages that uses internal data is quite large. Some of them extends the Dict, so they have a good reason to use it. You can find some of them by checking in #44332, where I have tried to make the code backward compatible.

[DNF2]

do you have an example of someone using this outside of base?

https://discourse.julialang.org/t/dictionary-showing-invalid-keys/96422/1

Does this mean, however, that all non-public fields should now have a leading underscore? Otherwise, this becomes inconsistent and confusing.

[CameronBieganek]

Does this mean, however, that all non-public fields should now have a leading underscore? Otherwise, this becomes inconsistent and confusing.

No, there is no such proscription. As always, fields can be named anything we want. I don't think renaming two fields is a cause for confusion.

This will break a lot of code out there. Does not seem worth the churn.

It's unfortunate that we can't make non-breaking changes in Base without breaking things.

[KristofferC]

It's unfortunate that we can't make non-breaking changes in Base without breaking things.

Yes, a pragmatic view always has to be taken. But you could try open a PR, run PkgEval, see the level of breakage and maybe fix those packages etc.

[DNF2]

No, there is no such proscription. As always, fields can be named anything we want. I don't think renaming two fields is a cause for confusion.

What I meant is this: If one starts prepending underscores to signal that some fields are internal, what does that say about the fields that do not have leading underscores?

This should either be a convention to be followed more generally, or it risks encouraging people to access internal fields in some cases.