Or you change it and respond with “You were warned”.
I seriously do not get this take. People use reflection and all kinds of hacks to get at internals, this should not stop you from changing said internals.
There will always be users who do the wrong thing.
Let's say I'm in a large company. Someone on some other team decided to rely on my implementation internals for a key revenue driver, and snuck it through code review.
I can't break their app without them complaining to my boss's boss's boss who will take their side because their app creates money for the company.
Having actual private fields doesn't 100% prevent this scenario, but it makes it less likely to sneak through code review before it becomes business-critical.
> If you "just" rely on them not to do that, then your internals will effectively be frozen forever.
Or they will be broken when you change them and they upgrade. The JavaScript ecosystem uses this convention and generally if a field is prefixed by an underscore and/or documented as being non-public then you can expect to break in future versions (and this happens frequently in practice).
Not necessarily saying that's better, but it is another choice that's available.
