[swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Rick Mann]

> On Sep 17, 2017, at 03:25 , Quinn The Eskimo! via swift-users <swift-users at swift.org> wrote:
> 
> 
> On 15 Sep 2017, at 21:35, Vladimir.S via swift-users <swift-users at swift.org> wrote:
> 
>> … for me it is very strange decision to disallow a method because it is 'expensive'.
> 
> That’s pretty normal for Swift standard library protocols, which define not just the behaviour of the routine but expected performance.  `popFirst()` is expected to be O(1) and that’s not possible with `Array`.
> 
> The rationale behind this decision is, I believe, related to generic algorithms.  If I write generic code that uses `popFirst()`, I can only guarantee the complexity of my code if I can rely on `popFirst()` being O(1).  If someone implements `popFirst()` as O(n), my generic algorithm might go from O(n^2) to O(n^3), which is quite a change.
> 
> On 16 Sep 2017, at 01:44, Rick Mann via swift-users <swift-users at swift.org> wrote:
> 
>> Is the compiler looking at the name "pop" and adding additional constraints (and then spewing a bogus error message)?
> 
> I’m not sure what’s going on here mechanically but, yes, the error message is bogus.  This is exactly what SR-5515 is talking about.
> 
> If I were in your shoes I’d call this method something other than `popFirst()`.  This falls under my standard “if you change the semantics, change the name” rule.  Your implementation of `popFirst()` doesn’t conform to the semantics of `popFirst()` — it’s O(n) because `removeFirst()` is O(n) — and thus you want to avoid calling it `popFirst()`.

All right, I'm happy to change the name to "safeRemoveFirst()", but I'm a bit irritated that there's an implicit performance constraint based on the name alone, without any obvious decorator syntax.


-- 
Rick Mann
rmann at latencyzero.com