I've seen the top 5 implementations, I was rather interested in the specific declarations and implementations for:
24 "trim() -> String"
9 "trim()"
The last one seems to be mutating since there is no return type (Void implied) while the first one can potentially have mutating func trim() -> String declaration, no?
https://stackoverflow.com/a/24225160/3705470
Immutable as in the value type Int is immutable. Everytime you "change" it you are creating a new value. At least this is the mental model I have about swift's string.
Well if you mean that you have to destroy the previous storage after moving everything into a new one after mutation then yes it's kind of immutable in that sense, but that raises the question what is not immutable that is some sort of a collection type? However I don't think Int is immutable since you can mutate it in-place and it should change the allocated storage, no!?
But this is too much off-topic already and does not answer why we should drop the in-place mutating trim(for:) function.
I would argue that the SO entry is wrong. You can do bit opreations on Int and that doesn't entail a new assignement. And Strings are different anyway.
Even being different, they can reuse their memory space on mutation if they previously reserved enough space to do so.
I gave plenty of examples and reasons why not to include a mutation version of trim on string.
mutating trim is distracting right now. It also implies that the implementation is super efficient.
I would say, focus on the non mutation version, decide if this should return a substring. Get rid of the for options and provide a way to pass in an collections of characters.
add to the alternatives that a mutating version was considered and if enough people want it then it can be added later.
Right now, the proposal lacks clarity, I do not like the API (mutating and not).