fix #11028: std.bitmanip.write does not work with ranges with slicing

[jmdavis]

The basic problem here is that the code assumed that an immutable(ubyte)[] can be assigned to a slice of the range. It's technically possible to implement that with opIndexAssign, but it's highly unlikely that anyone has actually done that, particularly because that operation is not actually part of the range API. The other issue is that the template constraint did not check that the elements were assignable (individually or as a slice), which it needs to do if it's going to assign to the elements like it needs to; otherwise, ranges which pass the template constraint will fail to compile with the function.

These changes make it so that the template constraint verifies that the elements are assignable, and it upgrades the range requirement to a random-access range, whereas previously, it just required that the range be a forward range with slicing. Forward ranges with slicing are nonsensical, because if you can implement that, the range can easily be a random-access range. And since the odds of the code having compiled for anyone previously with anything other than arrays is extremely low, IMHO, it's just cleaner to require a random-access range with assignable elements rather than worrying about the bizarre corner case where a forward range has implemented slicing and an opIndexAssign which accepts immutable(ubyte)[], but the range hasn't implemented the functions required to be a random-access range.

So, there is a very small chance that this will cause a regression, but I'd be extremely surprised if it does.

Either way, it fixes it so that random-access ranges with assignable elements work with write, whereas realistically, all that worked previously was dynamic arrays.

[dlang-bot]

Thanks for your pull request, @jmdavis!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• In preparation for migrating from Bugzilla to GitHub Issues, the issue reference syntax has changed. Please add the word "Bugzilla" to issue references. For example, Fix Bugzilla Issue 12345 or Fix Bugzilla 12345.(Reminder: the edit needs to be done in the Git commit message, not the GitHub pull request.)

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#11032"

[Herringway]

This module seems to have a few reimplementations of std.algorithm.mutation.copy.