Implement buffer pointer's `MutableCollection` methods as nonmutating

[t-ae]

Currently this code is not compilable.

func median<T: Comparable>(bp: UnsafeMutableBufferPointer<T>) {
    bp.sort() // error: cannot use mutating member on immutable value: 'bp' is a 'let' constant
    return bp[bp.count/2]
}

It is because sort, defined in MutableColelction, is mutating.

UnsafeMutableBufferPointer has two mutability.

1. Mutability of itself
2. Mutability of buffer

If we want to mutate UnsafeMutableBufferPointer itself, we need to make it mutable.
But if we want to mutate only buffer, it doesn't have to be mutable.
mutating denotes the method mutates self, so it's not suitable for UnsafeMutableBufferPointer's sort.

In UnsafeMutableBufferPointer, subscript and swapAt, which mutate only buffer, are implemented as nonmutating .
Other methods, partition, reverse, shuffle, and sort, also mutate only buffer.
So it'll be consistent to make them nonmutating likewise.

What do you think?

Other types:

• UnsafeMutableRawBufferPointer also has this problem.
• UnsafeMutableAudioBufferListPointer also has this problem(But it's in CoreAudio).
• EmptyCollection's methods can be nonmutating since they do nothing.
• CollectionOfOne's methods, except subscript, also do nothing so they can be nonmutating.

[fclout]

Until this is discussed and decided, you can do var bp2 = bp; bp2.sort(); return bp2[bp2.count/2].

[glessard (Guillaume Lessard)]

I’m not sure this has been discussed as the main topic of a thread, but it was broached during the light discussion of SE-0237. I suggested giving the UnsafeBufferPointer types a nonmutating interface to MutableCollection, and that was turned down. In the core team’s first evaluation of the proposal, they cited a concern over having too many overloads. It does seem probable that such overloads might not pull their weight.

Review of SE-0237: Introduce Contiguous Collection Protocols

Hello Swift Community, The review of SE-0237 "Introduce Contiguous Collection Protocols" ran from November 16...27, 2018. The Core Team is returning this proposal for revision, with a few comments: The Core Team felt that the use of inout for the closure parameter of withUnsafeMutableBufferPointer(IfSupported) was the best available option, and noted that the library could verify that the UnsafeMutableBufferPointer itself wasn't directly modified by checking for the expected base address / co…

[t-ae]

@fclout

Until this is discussed and decided, you can do var bp2 = bp; bp2.sort(); return bp2[bp2.count/2] .

I know it, of course🙂

@glessard

I’m not sure this has been discussed as the main topic of a thread, but it was broached during the light discussion of SE-0237. I suggested giving the UnsafeBufferPointer types a nonmutating interface to MutableCollection, and that was turned down. In the core team’s first evaluation of the proposal, they cited a concern over having too many overloads. It does seem probable that such overloads might not pull their weight.

I didn't find these posts. It seems your PR contains what I'm suggesting.
Before posting this thread, I thought it would be troublesome to overload all methods. But also thought it's worth discussing which we should take, code simplicity or consistency.