feat(array): impl public methods of Array for ArrayView

[FlammeShadow]

• Feature request: ArrayView should have all the public methods that Array has #1013

Most of the implementation of functions and tests are taken from Array, except for some slight changes.

Some notes:

• Self-modifying methods
  • Methods that changed the length are left not implemented, not sure about that should they be implemented on ArrayView
  • I think they should not be implemented because an arrayview is only a slice and its start and end are immutable.
• repeat
• flatten
  • I am not sure whether it should accept ArrayView[ArrayView[T]].
  • The other ones returned Array[Array[T]] are directly transformed into returning ArrayView[ArrayView[T]].
  • Implmented using push_iter at now. (migrating to UninitializedArray::unsafe_blit?)
• The impl of rev, flatten maybe naive.
• The impl of op_equal doesn't concern start and end.
• The in-place methods will affect the original array.

[coveralls]

Pull Request Test Coverage Report for Build 4133

Details

• 38 of 94 (40.43%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.7%) to 80.163%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
builtin/arrayview.mbt	0	24	0.0%
array/view.mbt	34	66	51.52%

Totals
Change from base Build 4132:	-0.7%
Covered Lines:	4530
Relevant Lines:	5651

---

💛 - Coveralls

[peter-jerry-ye]

Could you please run moon info and commit the changes to the interface files?

[FlammeShadow]

Could you please run moon info and commit the changes to the interface files?

Sure. I will do it once I add the rest functions.

Edited: Done.

[FlammeShadow]

Off-topic: It seems that running moon info on Windows (at least, on my machine?) will change the .mbti files from LF into CRLF and git will trace all of them.

[bobzhang]

hi @FlammeShadow thanks for your contributions.
In general, it would be nice to split changes to small contributions so that it is easier to review, take this PR for example, it would be nice to submit changes to different packages separately.

For ArrayView, we would take it as view so that it does not own the resource, in that case, we are happy to add APIs like contains but not copy, the latter requires the allocation of a new view, which defeats the purpose

[gmlewis]

I am really needing the ability to map an ArrayView in my own code, so I wrote this PR: #1321.
After I wrote that, I found this PR, but am not happy about the implementation found here.

I believe that it is MUCH more flexible for the map* functions to return an Array (not an ArrayView).
Then, code that was performing a map on an entire array could easily insert a [1:] and now map all but the first entry without modifying any other code.

Additionally, it is much easier to turn an Array into an ArrayView than to go the other direction.

[FlammeShadow]

You're pretty right.

[FlammeShadow]

hi @FlammeShadow thanks for your contributions.
In general, it would be nice to split changes to small contributions so that it is easier to review, take this PR for example, it would be nice to submit changes to different packages separately.

For ArrayView, we would take it as view so that it does not own the resource, in that case, we are happy to add APIs like contains but not copy, the latter requires the allocation of a new view, which defeats the purpose

OK. I understand.