fix issue 15364 - BitArray.len should be private

[ghost]

No description provided.

[dlang-bot]

Fix	Bugzilla	Description
✓	15364	BitArray.len should be private

[JakobOvrum]

LGTM

[JackStouffer]

LGTM

[schveiguy]

These public members were all not documented, so it makes sense that we don't need to worry about breakage (e.g. bitsPerSizeT was harmlessly public)

[schveiguy]

whitelisted @Blumerline

[schveiguy]

Auto-merge toggled on

[JackStouffer]

whitelisted @Blumerline

Whitelisted for what?

[schveiguy]

Whitelisted for what?

autotester.

[WalterBright]

Yeah, except they did break things :-(

[schveiguy]

Any broken code was using undocumented features that were not meant to be accessible. If read-only access is necessary, then we can add public accessors. But ptr and len should not be writable.

[MartinNowak]

We always need to worry about breakage, this was so unnecessary.
Nobody would have an issue w/ properly deprecating access to those fields, but just randomly breaking code b/c sth. should have been done different years ago is unacceptable.
#3950

[schveiguy]

No, changing len or ptr or both externally is neither supported nor could possibly be accepted as valid code.

Any code that broke because of this had a bug, and now the person would see the bug should be fixed. We did anyone who's code broke a favor.

This is like saying fixing a buffer overrun broke my code.

[Hackerpilot]

http://imgs.xkcd.com/comics/workflow.png

[MartinNowak]

Any code that broke because of this had a bug, and now the person would see the bug should be fixed. We did anyone who's code broke a favor.

It certainly wasn't used incorrectly in undead, and every breakage we introduce requires library maintainers to release new versions and uses to update their dependencies.
If we don't deprecate such changes properly we cause a lot of downstream work and devaluate existing D code. We should be more careful with our tiny ecosystem.

[schveiguy]

It certainly wasn't used incorrectly in undead

Certainly it wasn't when it was part of Phobos. As a separate 3rd party library (and isn't this the entire purpose of this library, to maintain support with the current phobos?), it should not be accessing internals of Phobos implementation. So yes, it was used incorrectly (although now fixed).

We can agree to disagree on this. I don't think we should cater or support any 3rd party library that uses internal details of Phobos implementations. You can disagree with that, but I can't have any care or sympathy for those libraries, sorry.

[MartinNowak]

We don't disagree on the fact that internals should be internal, but I'm arguing against simply breaking things b/c someone made a mistake years ago. The cost of properly deprecating those fields is literally zero.