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

[Quinn "The Eskimo!" via swift-users]

On 18 Sep 2017, at 13:52, Vladimir.S  wrote:

> Can't understand/accept this, sorry.

You seem to be very invested in how Swift /should/ work, rather than how it 
/does/ work.  I’m sympathetic with that position but it’s really a topic of 
conversation for swift-evolution rather than swift-users.

> Also, could you clarify, why .removeFirst() is different?

`removeFirst()` is marked as O(n), and thus it’s fully expected that it’d work 
on `Array`.

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Vladimir.S via swift-users]

On 17.09.2017 13:25, Quinn "The Eskimo!" via swift-users wrote:


On 15 Sep 2017, at 21:35, Vladimir.S via swift-users  
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.


Do I understand this correctly?: To protect *me* from using popFirst() with possible 
O(n) complexity in my *generic code*, there is no better solution in Swift than just 
*hide* the method from me even in non-generic code. Even if I probably don't care 
about the complexity for my 5 elements array.
And so, I should use hacky code like this(which doesn't produce warnings/errors) to 
fight with compiler:

let x = array[0...].popFirst()

Can't understand/accept this, sorry. If you are saying "this is a current limitation 
we have" - ok, but when you are saying "That’s pretty normal" - I don't understand 
what "normal" means here. I even can understand if compiler can provide us with some 
'popFirstNComplexity()'(or warning with a way to silence it) when 'popFirst' 
shouldn't be accessible because of reasons mentioned by you. But just hide the method.



Also, could you clarify, why .removeFirst() is different? We can use it without 
problems:

var array = [1, 2, 3, 4, 5]
array.removeFirst() // no warnings
print(array) // [2,3,4,5]

Vladimir.



On 16 Sep 2017, at 01:44, Rick Mann via swift-users  
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()`.

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Geordie Jay via swift-users]

It seems to me that some of these concerns could be fixed by returning
ArraySlice instead of Array on popFirst(). Then you’d have similar
performance expectations and explicit copying like with String / Substring.

Geordie


Elia Cereda via swift-users  schrieb am Mo. 18. Sep.
2017 um 11:12:

> NSMutableArray does provide O(1) insertion and removal from the start and
> the end of the array (
> http://ciechanowski.me/blog/2014/03/05/exposing-nsmutablearray/).
>
> I think the reason Swift doesn't use this design is because it stores the
> data in a contiguous block of memory.
>
> Elia Cereda
>
> Il giorno 18 set 2017, alle ore 04:48, Jon Shier via swift-users <
> swift-users@swift.org> ha scritto:
>
> Yes, it seems to fly in the face of protocols as they exist in Swift at
> the moment. Given the inability of protocols to guarantee performance
> characteristics, breaking conformant types like this seems like a bad way
> to try and fulfill a separate axis of concern. Wouldn’t a better idea be to
> move things like popFirst(), and other methods requiring O(1) performance,
> to a separate protocol? I’m also pretty sure it’s possible to implement
> popFirst in O(1) for an Array, but Swift’s Array isn't generally very fast,
> at least compared to C / C++.
>
>
>
> Jon
>
> On Sep 17, 2017, at 9:45 PM, Rick Mann via swift-users <
> swift-users@swift.org> wrote:
>
>
> On Sep 17, 2017, at 03:25 , Quinn The Eskimo! via swift-users <
> swift-users@swift.org> wrote:
>
>
> On 15 Sep 2017, at 21:35, Vladimir.S via swift-users <
> swift-users@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 
> 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
> rm...@latencyzero.com
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Elia Cereda via swift-users]

NSMutableArray does provide O(1) insertion and removal from the start and the 
end of the array 
(http://ciechanowski.me/blog/2014/03/05/exposing-nsmutablearray/). 

I think the reason Swift doesn't use this design is because it stores the data 
in a contiguous block of memory. 

Elia Cereda

> Il giorno 18 set 2017, alle ore 04:48, Jon Shier via swift-users 
>  ha scritto:
> 
>   Yes, it seems to fly in the face of protocols as they exist in Swift at 
> the moment. Given the inability of protocols to guarantee performance 
> characteristics, breaking conformant types like this seems like a bad way to 
> try and fulfill a separate axis of concern. Wouldn’t a better idea be to move 
> things like popFirst(), and other methods requiring O(1) performance, to a 
> separate protocol? I’m also pretty sure it’s possible to implement popFirst 
> in O(1) for an Array, but Swift’s Array isn't generally very fast, at least 
> compared to C / C++.
> 
> 
> 
> Jon
> 
>>> On Sep 17, 2017, at 9:45 PM, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On Sep 17, 2017, at 03:25 , Quinn The Eskimo! via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On 15 Sep 2017, at 21:35, Vladimir.S via swift-users 
>>>  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 
  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
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Jon Shier via swift-users]

Yes, it seems to fly in the face of protocols as they exist in Swift at 
the moment. Given the inability of protocols to guarantee performance 
characteristics, breaking conformant types like this seems like a bad way to 
try and fulfill a separate axis of concern. Wouldn’t a better idea be to move 
things like popFirst(), and other methods requiring O(1) performance, to a 
separate protocol? I’m also pretty sure it’s possible to implement popFirst in 
O(1) for an Array, but Swift’s Array isn't generally very fast, at least 
compared to C / C++.



Jon

> On Sep 17, 2017, at 9:45 PM, Rick Mann via swift-users 
>  wrote:
> 
>> 
>> On Sep 17, 2017, at 03:25 , Quinn The Eskimo! via swift-users 
>>  wrote:
>> 
>> 
>> On 15 Sep 2017, at 21:35, Vladimir.S via swift-users  
>> 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  
>> 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
> rm...@latencyzero.com 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Rick Mann via swift-users]

> On Sep 17, 2017, at 03:25 , Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 15 Sep 2017, at 21:35, Vladimir.S via swift-users  
> 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  
> 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
rm...@latencyzero.com


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Quinn "The Eskimo!" via swift-users]

On 15 Sep 2017, at 21:35, Vladimir.S via swift-users  
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  
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()`.

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Rick Mann via swift-users]

In my case, it's my own implementation of popFirst(), so I'm not sure why it's 
complaining at all. Who cares if it's slow? The declaration is identical to 
popLast(), with the exception that I'm defining mine in an extension that's not 
Generic (I don't know if you can do it any other way). But otherwise, my 
declaration is identical to popLast().

Is the compiler looking at the name "pop" and adding additional constraints 
(and then spewing a bogus error message)?


> On Sep 15, 2017, at 13:35 , Vladimir.S via swift-users 
>  wrote:
> 
> On 14.09.2017 22:02, Jon Shier via swift-users wrote:
>> Looks like this is sort of tracked in  SR-5515popFirst error message is 
>> silly . I’m not sure what a good 
>> answer is here, since it seems like it isn’t supposed to be available if it 
>> can’t guarantee O(1) behavior. Still seems like Array should have it, but in 
>> any case, this looks like a bad error message at least.
> 
> But can .removeFirst() guarantee this? I don't believe these two methods a 
> very different in implementation. And, as I said, for me it is very strange 
> decision to disallow a method because it is 'expensive'. I hope this is just 
> a bug, that will be fixed.
> 
> Vladimir.
> 
>> Jon
>>> On Sep 14, 2017, at 11:05 AM, Jon Shier via swift-users 
>>> > wrote:
>>> 
>>> This seems oddly similar to https://bugs.swift.org/browse/SR-5659, but 
>>> [Thing] should meet the appropriate criteria for popFirst to work properly. 
>>> Yet the error we’re seeing here is the same that was originally seen when 
>>> trying to use popFirst on a String. Definitely feels like some sort of 
>>> Swift bug here.
>>> 
>>> 
>>> 
>>> Jon
>>> 
>>> 
 On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users 
 > wrote:
 
 It also doesn’t explain why removeFirst would work but popFirst doesn’t. 
 The mutation to the underlying array should be the same, the only 
 different is that one returns the element optionally. It also doesn’t 
 explain why popFirst doesn’t show up I the autocomplete but compiles 
 anyway.
 
 
 
 Jon
 
> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
> > wrote:
> 
> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
>> On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
>> > wrote:
>>> popFirst is not available in the Array …
>> Right.  This makes sense when you consider the standard setup for an 
>> array, namely, a variable length buffer of items.  Removing the first 
>> element is expensive, whereas removing the last element (`popLast()`) is 
>> cheap.
>> If you run your simplified example in Xcode 8 you get an error that 
>> hints at what’s going on.
>> var array = [1, 2, 3, 4, 5]
>> _ = array.popFirst()
>>~~^~~~
>> error: 'ArraySlice' is not convertible to '[Int]'
> 
> Sorry, could you clarify, I can't understand.
> What should be the error message here and why at all we should have an 
> error here?
> 
> Are we forced to use this code to pop first element in array? :
> var array = [1, 2, 3, 4, 5]
> let x = array[0...].popFirst()
> print(x!) // 1
> print(array) // [2,3,4,5]
> 
> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
> expensive, but is it a right reason to disallow it totally? In many 
> situations we have a small arrays and don't care so much how fast the 
> first element will be pop'ed.
> I hope I'm just missing something.
> 
> Vladimir.
> 
>> Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 
>> with a new command line tool project) and I get the same error there.
>> let mf = self.pendingFetchers.popFirst()
>> ~^~~~
>> error: 'ArraySlice' is not convertible to '[ModelFetcher]’
>>   *   *   *
>> @Rick, there’s two things in play here:
>> * The diagnostic is clearly bogus and you should definitely file a bug 
>> about that.
>> 
>> Please post your bug number, just for the record.
>> * You wrote:
>>> This code compiled fine in Xcode 8 …
>> My tests indicate that it doesn’t.  I suspect that you changed something 
>> else during the Swift 4 migration and that’s why you’re seeing it fail.  
>> Can you take another look at the original Xcode 8 code to see what’s 
>> else got changed?
>> Share and Enjoy
>> --
>> Quinn "The Eskimo!"
>> Apple Developer Relations, Developer Technical Support, Core 

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

[Vladimir.S via swift-users]

On 14.09.2017 22:02, Jon Shier via swift-users wrote:
Looks like this is sort of tracked in  SR-5515popFirst error message is silly 
. I’m not sure what a good answer is here, 
since it seems like it isn’t supposed to be available if it can’t guarantee O(1) 
behavior. Still seems like Array should have it, but in any case, this looks like a 
bad error message at least.


But can .removeFirst() guarantee this? I don't believe these two methods a very 
different in implementation. And, as I said, for me it is very strange decision to 
disallow a method because it is 'expensive'. I hope this is just a bug, that will be 
fixed.


Vladimir.





Jon


On Sep 14, 2017, at 11:05 AM, Jon Shier via swift-users > wrote:


This seems oddly similar to https://bugs.swift.org/browse/SR-5659, but [Thing] 
should meet the appropriate criteria for popFirst to work properly. Yet the error 
we’re seeing here is the same that was originally seen when trying to use popFirst 
on a String. Definitely feels like some sort of Swift bug here.




Jon


On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users > wrote:


It also doesn’t explain why removeFirst would work but popFirst doesn’t. The 
mutation to the underlying array should be the same, the only different is that 
one returns the element optionally. It also doesn’t explain why popFirst doesn’t 
show up I the autocomplete but compiles anyway.




Jon

On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users > wrote:


On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
On 14 Sep 2017, at 03:56, somu subscribe via swift-users > wrote:

popFirst is not available in the Array …
Right.  This makes sense when you consider the standard setup for an array, 
namely, a variable length buffer of items.  Removing the first element is 
expensive, whereas removing the last element (`popLast()`) is cheap.
If you run your simplified example in Xcode 8 you get an error that hints at 
what’s going on.

var array = [1, 2, 3, 4, 5]
_ = array.popFirst()
~~^~~~
error: 'ArraySlice' is not convertible to '[Int]'


Sorry, could you clarify, I can't understand.
What should be the error message here and why at all we should have an error 
here?

Are we forced to use this code to pop first element in array? :
var array = [1, 2, 3, 4, 5]
let x = array[0...].popFirst()
print(x!) // 1
print(array) // [2,3,4,5]

And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
expensive, but is it a right reason to disallow it totally? In many situations we 
have a small arrays and don't care so much how fast the first element will be pop'ed.

I hope I'm just missing something.

Vladimir.

Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a new 
command line tool project) and I get the same error there.

let mf = self.pendingFetchers.popFirst()
 ~^~~~
error: 'ArraySlice' is not convertible to '[ModelFetcher]’
   *   *   *
@Rick, there’s two things in play here:
* The diagnostic is clearly bogus and you should definitely file a bug about 
that.

Please post your bug number, just for the record.
* You wrote:

This code compiled fine in Xcode 8 …
My tests indicate that it doesn’t.  I suspect that you changed something else 
during the Swift 4 migration and that’s why you’re seeing it fail.  Can you take 
another look at the original Xcode 8 code to see what’s else got changed?

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
___
swift-users mailing list
swift-users@swift.org 
https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org 
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org 
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org 
https://lists.swift.org/mailman/listinfo/swift-users




___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Rick Mann via swift-users]

I meant to add: I implemented it based on the declaration of popLast().

> On Sep 15, 2017, at 13:05 , Roderick Mann via swift-users 
>  wrote:
> 
> 
>> On Sep 13, 2017, at 18:59 , Jon Shier  wrote:
>> 
>>  I think there’s something strange with popFirst. It doesn’t show up in 
>> the autocomplete in Xcode, but it compiles, and popLast doesn’t throw the 
>> same error. removeFirst doesn’t either, though it’s unsafe. Weird.
> 
> extension
> Array
> {
>   public
>   mutating
>   func
>   popFirst()
>   -> Array.Element?
>   {
>   if self.count > 0
>   {
>   return self.removeFirst()
>   }
>   
>   return nil
>   }
> }
> 
>> 
> 
>> 
>> 
>> Jon
>> 
>> 
>>> On Sep 13, 2017, at 9:47 PM, Zhao Xin via swift-users 
>>>  wrote:
>>> 
>>> I begin to think it is related to how you `popFirst()` implemented. Check 
>>> it or post it here.
>>> 
>>> Zhao Xin
>>> 
>>> On Thu, Sep 14, 2017 at 9:36 AM, Roderick Mann  
>>> wrote:
>>> Yeah, that's not it. I made the change you suggested, I get the same error.
>>> 
 On Sep 13, 2017, at 18:11 , Zhao Xin  wrote:
 
 Change `self` to `ModelFetcher`. You are calling a class static property, 
 not a class instance property.
 
 Zhao Xin
 
 On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
  wrote:
 Moving to Swift 4, I'm running into an issue for which I can't seem to 
 find an answer in google:
 
 "Cannot use mutating member on immutable value: 'self' is immutable"
 
 The code looks like:
 
 class
 ModelFetcher : NSObject, URLSessionDelegate
 {
...
static  let managerDispatchQueue=   
 DispatchQueue(label: "Model Download Manager Queue")
static  var pendingFetchers =   
 [ModelFetcher]()
static  var currentFetcher: ModelFetcher?
 
class
func
startNextFetcher()
{
self.managerDispatchQueue.async
{
guard
self.currentFetcher == nil,
let mf = self.pendingFetchers.popFirst()
  ^ error: cannot 
 use mutating member on immutable value: 'self' is immutable
else
{
return
}
 
self.currentFetcher = mf
mf.start()
}
}
...
 }
 
 This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a 
 monolithic app (the error shows up when this code is factored into a 
 framework). Other mutating references to self seem to compile okay (e.g. 
 "self.currentFetcher = nil" or "self.pendingFetchers.remove(at: idx)"). 
 Not sure what's special about this one.
 
 
 --
 Rick Mann
 rm...@latencyzero.com
 
 
 ___
 swift-users mailing list
 swift-users@swift.org
 https://lists.swift.org/mailman/listinfo/swift-users
 
>>> 
>>> 
>>> --
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users


-- 
Rick Mann
rm...@latencyzero.com


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Roderick Mann via swift-users]

> On Sep 13, 2017, at 18:59 , Jon Shier  wrote:
> 
>   I think there’s something strange with popFirst. It doesn’t show up in 
> the autocomplete in Xcode, but it compiles, and popLast doesn’t throw the 
> same error. removeFirst doesn’t either, though it’s unsafe. Weird.

extension
Array
{
public
mutating
func
popFirst()
-> Array.Element?
{
if self.count > 0
{
return self.removeFirst()
}

return nil
}
}

> 

> 
> 
> Jon
> 
> 
>> On Sep 13, 2017, at 9:47 PM, Zhao Xin via swift-users 
>>  wrote:
>> 
>> I begin to think it is related to how you `popFirst()` implemented. Check it 
>> or post it here.
>> 
>> Zhao Xin
>> 
>> On Thu, Sep 14, 2017 at 9:36 AM, Roderick Mann  wrote:
>> Yeah, that's not it. I made the change you suggested, I get the same error.
>> 
>> > On Sep 13, 2017, at 18:11 , Zhao Xin  wrote:
>> >
>> > Change `self` to `ModelFetcher`. You are calling a class static property, 
>> > not a class instance property.
>> >
>> > Zhao Xin
>> >
>> > On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
>> >  wrote:
>> > Moving to Swift 4, I'm running into an issue for which I can't seem to 
>> > find an answer in google:
>> >
>> > "Cannot use mutating member on immutable value: 'self' is immutable"
>> >
>> > The code looks like:
>> >
>> > class
>> > ModelFetcher : NSObject, URLSessionDelegate
>> > {
>> > ...
>> > static  let managerDispatchQueue=   
>> > DispatchQueue(label: "Model Download Manager Queue")
>> > static  var pendingFetchers =   
>> > [ModelFetcher]()
>> > static  var currentFetcher: ModelFetcher?
>> >
>> > class
>> > func
>> > startNextFetcher()
>> > {
>> > self.managerDispatchQueue.async
>> > {
>> > guard
>> > self.currentFetcher == nil,
>> > let mf = self.pendingFetchers.popFirst()
>> >   ^ error: cannot 
>> > use mutating member on immutable value: 'self' is immutable
>> > else
>> > {
>> > return
>> > }
>> >
>> > self.currentFetcher = mf
>> > mf.start()
>> > }
>> > }
>> > ...
>> > }
>> >
>> > This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a 
>> > monolithic app (the error shows up when this code is factored into a 
>> > framework). Other mutating references to self seem to compile okay (e.g. 
>> > "self.currentFetcher = nil" or "self.pendingFetchers.remove(at: idx)"). 
>> > Not sure what's special about this one.
>> >
>> >
>> > --
>> > Rick Mann
>> > rm...@latencyzero.com
>> >
>> >
>> > ___
>> > swift-users mailing list
>> > swift-users@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-users
>> >
>> 
>> 
>> --
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 


-- 
Rick Mann
rm...@latencyzero.com


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Jon Shier via swift-users]

Looks like this is sort of tracked in  SR-5515popFirst error message is 
silly . I’m not sure what a good answer 
is here, since it seems like it isn’t supposed to be available if it can’t 
guarantee O(1) behavior. Still seems like Array should have it, but in any 
case, this looks like a bad error message at least.



Jon


> On Sep 14, 2017, at 11:05 AM, Jon Shier via swift-users 
>  wrote:
> 
>   This seems oddly similar to https://bugs.swift.org/browse/SR-5659 
> , but [Thing] should meet the 
> appropriate criteria for popFirst to work properly. Yet the error we’re 
> seeing here is the same that was originally seen when trying to use popFirst 
> on a String. Definitely feels like some sort of Swift bug here.
> 
> 
> 
> Jon
> 
> 
>> On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users 
>> > wrote:
>> 
>>  It also doesn’t explain why removeFirst would work but popFirst 
>> doesn’t. The mutation to the underlying array should be the same, the only 
>> different is that one returns the element optionally. It also doesn’t 
>> explain why popFirst doesn’t show up I the autocomplete but compiles anyway.
>> 
>> 
>> 
>> Jon
>> 
>>> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
>>> > wrote:
>>> 
>>> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
 On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
 > wrote:
> popFirst is not available in the Array …
 Right.  This makes sense when you consider the standard setup for an 
 array, namely, a variable length buffer of items.  Removing the first 
 element is expensive, whereas removing the last element (`popLast()`) is 
 cheap.
 If you run your simplified example in Xcode 8 you get an error that hints 
 at what’s going on.
 var array = [1, 2, 3, 4, 5]
 _ = array.popFirst()
 ~~^~~~
 error: 'ArraySlice' is not convertible to '[Int]'
>>> 
>>> Sorry, could you clarify, I can't understand.
>>> What should be the error message here and why at all we should have an 
>>> error here?
>>> 
>>> Are we forced to use this code to pop first element in array? :
>>> var array = [1, 2, 3, 4, 5]
>>> let x = array[0...].popFirst()
>>> print(x!) // 1
>>> print(array) // [2,3,4,5]
>>> 
>>> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
>>> expensive, but is it a right reason to disallow it totally? In many 
>>> situations we have a small arrays and don't care so much how fast the first 
>>> element will be pop'ed.
>>> I hope I'm just missing something.
>>> 
>>> Vladimir.
>>> 
 Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with 
 a new command line tool project) and I get the same error there.
 let mf = self.pendingFetchers.popFirst()
  ~^~~~
 error: 'ArraySlice' is not convertible to '[ModelFetcher]’
*   *   *
 @Rick, there’s two things in play here:
 * The diagnostic is clearly bogus and you should definitely file a bug 
 about that.
 >
 Please post your bug number, just for the record.
 * You wrote:
> This code compiled fine in Xcode 8 …
 My tests indicate that it doesn’t.  I suspect that you changed something 
 else during the Swift 4 migration and that’s why you’re seeing it fail.  
 Can you take another look at the original Xcode 8 code to see what’s else 
 got changed?
 Share and Enjoy
 --
 Quinn "The Eskimo!">
 Apple Developer Relations, Developer Technical Support, Core OS/Hardware
 ___
 swift-users mailing list
 swift-users@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-users 
 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org

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

[Jon Shier via swift-users]

This seems oddly similar to https://bugs.swift.org/browse/SR-5659, but 
[Thing] should meet the appropriate criteria for popFirst to work properly. Yet 
the error we’re seeing here is the same that was originally seen when trying to 
use popFirst on a String. Definitely feels like some sort of Swift bug here.



Jon


> On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users 
>  wrote:
> 
>   It also doesn’t explain why removeFirst would work but popFirst 
> doesn’t. The mutation to the underlying array should be the same, the only 
> different is that one returns the element optionally. It also doesn’t explain 
> why popFirst doesn’t show up I the autocomplete but compiles anyway.
> 
> 
> 
> Jon
> 
>> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
>> > wrote:
>> 
>> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
>>> On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
>>> > wrote:
 popFirst is not available in the Array …
>>> Right.  This makes sense when you consider the standard setup for an array, 
>>> namely, a variable length buffer of items.  Removing the first element is 
>>> expensive, whereas removing the last element (`popLast()`) is cheap.
>>> If you run your simplified example in Xcode 8 you get an error that hints 
>>> at what’s going on.
>>> var array = [1, 2, 3, 4, 5]
>>> _ = array.popFirst()
>>> ~~^~~~
>>> error: 'ArraySlice' is not convertible to '[Int]'
>> 
>> Sorry, could you clarify, I can't understand.
>> What should be the error message here and why at all we should have an error 
>> here?
>> 
>> Are we forced to use this code to pop first element in array? :
>> var array = [1, 2, 3, 4, 5]
>> let x = array[0...].popFirst()
>> print(x!) // 1
>> print(array) // [2,3,4,5]
>> 
>> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
>> expensive, but is it a right reason to disallow it totally? In many 
>> situations we have a small arrays and don't care so much how fast the first 
>> element will be pop'ed.
>> I hope I'm just missing something.
>> 
>> Vladimir.
>> 
>>> Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with 
>>> a new command line tool project) and I get the same error there.
>>> let mf = self.pendingFetchers.popFirst()
>>>  ~^~~~
>>> error: 'ArraySlice' is not convertible to '[ModelFetcher]’
>>>*   *   *
>>> @Rick, there’s two things in play here:
>>> * The diagnostic is clearly bogus and you should definitely file a bug 
>>> about that.
>>> >
>>> Please post your bug number, just for the record.
>>> * You wrote:
 This code compiled fine in Xcode 8 …
>>> My tests indicate that it doesn’t.  I suspect that you changed something 
>>> else during the Swift 4 migration and that’s why you’re seeing it fail.  
>>> Can you take another look at the original Xcode 8 code to see what’s else 
>>> got changed?
>>> Share and Enjoy
>>> --
>>> Quinn "The Eskimo!">> >
>>> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Jon Shier via swift-users]

It also doesn’t explain why removeFirst would work but popFirst 
doesn’t. The mutation to the underlying array should be the same, the only 
different is that one returns the element optionally. It also doesn’t explain 
why popFirst doesn’t show up I the autocomplete but compiles anyway.



Jon

> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
>  wrote:
> 
> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
>> On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
>> > wrote:
>>> popFirst is not available in the Array …
>> Right.  This makes sense when you consider the standard setup for an array, 
>> namely, a variable length buffer of items.  Removing the first element is 
>> expensive, whereas removing the last element (`popLast()`) is cheap.
>> If you run your simplified example in Xcode 8 you get an error that hints at 
>> what’s going on.
>> var array = [1, 2, 3, 4, 5]
>> _ = array.popFirst()
>> ~~^~~~
>> error: 'ArraySlice' is not convertible to '[Int]'
> 
> Sorry, could you clarify, I can't understand.
> What should be the error message here and why at all we should have an error 
> here?
> 
> Are we forced to use this code to pop first element in array? :
> var array = [1, 2, 3, 4, 5]
> let x = array[0...].popFirst()
> print(x!) // 1
> print(array) // [2,3,4,5]
> 
> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
> expensive, but is it a right reason to disallow it totally? In many 
> situations we have a small arrays and don't care so much how fast the first 
> element will be pop'ed.
> I hope I'm just missing something.
> 
> Vladimir.
> 
>> Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a 
>> new command line tool project) and I get the same error there.
>> let mf = self.pendingFetchers.popFirst()
>>  ~^~~~
>> error: 'ArraySlice' is not convertible to '[ModelFetcher]’
>>*   *   *
>> @Rick, there’s two things in play here:
>> * The diagnostic is clearly bogus and you should definitely file a bug about 
>> that.
>> 
>> Please post your bug number, just for the record.
>> * You wrote:
>>> This code compiled fine in Xcode 8 …
>> My tests indicate that it doesn’t.  I suspect that you changed something 
>> else during the Swift 4 migration and that’s why you’re seeing it fail.  Can 
>> you take another look at the original Xcode 8 code to see what’s else got 
>> changed?
>> Share and Enjoy
>> --
>> Quinn "The Eskimo!"
>> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Vladimir.S via swift-users]

On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:


On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
 wrote:


popFirst is not available in the Array …


Right.  This makes sense when you consider the standard setup for an array, 
namely, a variable length buffer of items.  Removing the first element is 
expensive, whereas removing the last element (`popLast()`) is cheap.

If you run your simplified example in Xcode 8 you get an error that hints at 
what’s going on.

var array = [1, 2, 3, 4, 5]
_ = array.popFirst()
 ~~^~~~
error: 'ArraySlice' is not convertible to '[Int]'



Sorry, could you clarify, I can't understand.
What should be the error message here and why at all we should have an error 
here?

Are we forced to use this code to pop first element in array? :
var array = [1, 2, 3, 4, 5]
let x = array[0...].popFirst()
print(x!) // 1
print(array) // [2,3,4,5]

And why we shouldn't be allowed to have popFirst() for array? Yes, it is expensive, 
but is it a right reason to disallow it totally? In many situations we have a small 
arrays and don't care so much how fast the first element will be pop'ed.

I hope I'm just missing something.

Vladimir.


Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a 
new command line tool project) and I get the same error there.

let mf = self.pendingFetchers.popFirst()
  ~^~~~
error: 'ArraySlice' is not convertible to '[ModelFetcher]’

*   *   *

@Rick, there’s two things in play here:

* The diagnostic is clearly bogus and you should definitely file a bug about 
that.



Please post your bug number, just for the record.

* You wrote:


This code compiled fine in Xcode 8 …


My tests indicate that it doesn’t.  I suspect that you changed something else 
during the Swift 4 migration and that’s why you’re seeing it fail.  Can you 
take another look at the original Xcode 8 code to see what’s else got changed?

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Quinn "The Eskimo!" via swift-users]

On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
 wrote:

> popFirst is not available in the Array …

Right.  This makes sense when you consider the standard setup for an array, 
namely, a variable length buffer of items.  Removing the first element is 
expensive, whereas removing the last element (`popLast()`) is cheap.

If you run your simplified example in Xcode 8 you get an error that hints at 
what’s going on.

var array = [1, 2, 3, 4, 5]
_ = array.popFirst()
~~^~~~
error: 'ArraySlice' is not convertible to '[Int]'

Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a 
new command line tool project) and I get the same error there.

let mf = self.pendingFetchers.popFirst()
 ~^~~~
error: 'ArraySlice' is not convertible to '[ModelFetcher]’

   *   *   *

@Rick, there’s two things in play here:

* The diagnostic is clearly bogus and you should definitely file a bug about 
that.



Please post your bug number, just for the record.

* You wrote:

> This code compiled fine in Xcode 8 …

My tests indicate that it doesn’t.  I suspect that you changed something else 
during the Swift 4 migration and that’s why you’re seeing it fail.  Can you 
take another look at the original Xcode 8 code to see what’s else got changed?

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[somu subscribe via swift-users]

Not sure why it is happening, but given below are my observations:

Simplified version:

var array = [1, 2, 3, 4, 5]
_ = array.popFirst() //error: cannot use mutating member on immutable value: 
'array' is immutable
_ = array.popLast() //works ok

popFirst is not available in the Array documentation and “Jump to Definition” 
doesn’t seem to work.

Thanks and regards,
Muthu


> On 14 Sep 2017, at 9:59 AM, Jon Shier via swift-users  
> wrote:
> 
>   I think there’s something strange with popFirst. It doesn’t show up in 
> the autocomplete in Xcode, but it compiles, and popLast doesn’t throw the 
> same error. removeFirst doesn’t either, though it’s unsafe. Weird.
> 
> 
> 
> Jon
> 
> 
>> On Sep 13, 2017, at 9:47 PM, Zhao Xin via swift-users > > wrote:
>> 
>> I begin to think it is related to how you `popFirst()` implemented. Check it 
>> or post it here.
>> 
>> Zhao Xin
>> 
>> On Thu, Sep 14, 2017 at 9:36 AM, Roderick Mann > > wrote:
>> Yeah, that's not it. I made the change you suggested, I get the same error.
>> 
>> > On Sep 13, 2017, at 18:11 , Zhao Xin > > > wrote:
>> >
>> > Change `self` to `ModelFetcher`. You are calling a class static property, 
>> > not a class instance property.
>> >
>> > Zhao Xin
>> >
>> > On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
>> > > wrote:
>> > Moving to Swift 4, I'm running into an issue for which I can't seem to 
>> > find an answer in google:
>> >
>> > "Cannot use mutating member on immutable value: 'self' is immutable"
>> >
>> > The code looks like:
>> >
>> > class
>> > ModelFetcher : NSObject, URLSessionDelegate
>> > {
>> > ...
>> > static  let managerDispatchQueue=   
>> > DispatchQueue(label: "Model Download Manager Queue")
>> > static  var pendingFetchers =   
>> > [ModelFetcher]()
>> > static  var currentFetcher: ModelFetcher?
>> >
>> > class
>> > func
>> > startNextFetcher()
>> > {
>> > self.managerDispatchQueue.async
>> > {
>> > guard
>> > self.currentFetcher == nil,
>> > let mf = self.pendingFetchers.popFirst()
>> >   ^ error: cannot 
>> > use mutating member on immutable value: 'self' is immutable
>> > else
>> > {
>> > return
>> > }
>> >
>> > self.currentFetcher = mf
>> > mf.start()
>> > }
>> > }
>> > ...
>> > }
>> >
>> > This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a 
>> > monolithic app (the error shows up when this code is factored into a 
>> > framework). Other mutating references to self seem to compile okay (e.g. 
>> > "self.currentFetcher = nil" or "self.pendingFetchers.remove(at: idx)"). 
>> > Not sure what's special about this one.
>> >
>> >
>> > --
>> > Rick Mann
>> > rm...@latencyzero.com 
>> >
>> >
>> > ___
>> > swift-users mailing list
>> > swift-users@swift.org 
>> > https://lists.swift.org/mailman/listinfo/swift-users 
>> > 
>> >
>> 
>> 
>> --
>> Rick Mann
>> rm...@latencyzero.com 
>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Jon Shier via swift-users]

I think there’s something strange with popFirst. It doesn’t show up in 
the autocomplete in Xcode, but it compiles, and popLast doesn’t throw the same 
error. removeFirst doesn’t either, though it’s unsafe. Weird.



Jon


> On Sep 13, 2017, at 9:47 PM, Zhao Xin via swift-users  
> wrote:
> 
> I begin to think it is related to how you `popFirst()` implemented. Check it 
> or post it here.
> 
> Zhao Xin
> 
> On Thu, Sep 14, 2017 at 9:36 AM, Roderick Mann  > wrote:
> Yeah, that's not it. I made the change you suggested, I get the same error.
> 
> > On Sep 13, 2017, at 18:11 , Zhao Xin  > > wrote:
> >
> > Change `self` to `ModelFetcher`. You are calling a class static property, 
> > not a class instance property.
> >
> > Zhao Xin
> >
> > On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
> > > wrote:
> > Moving to Swift 4, I'm running into an issue for which I can't seem to find 
> > an answer in google:
> >
> > "Cannot use mutating member on immutable value: 'self' is immutable"
> >
> > The code looks like:
> >
> > class
> > ModelFetcher : NSObject, URLSessionDelegate
> > {
> > ...
> > static  let managerDispatchQueue=   
> > DispatchQueue(label: "Model Download Manager Queue")
> > static  var pendingFetchers =   
> > [ModelFetcher]()
> > static  var currentFetcher: ModelFetcher?
> >
> > class
> > func
> > startNextFetcher()
> > {
> > self.managerDispatchQueue.async
> > {
> > guard
> > self.currentFetcher == nil,
> > let mf = self.pendingFetchers.popFirst()
> >   ^ error: cannot 
> > use mutating member on immutable value: 'self' is immutable
> > else
> > {
> > return
> > }
> >
> > self.currentFetcher = mf
> > mf.start()
> > }
> > }
> > ...
> > }
> >
> > This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a monolithic 
> > app (the error shows up when this code is factored into a framework). Other 
> > mutating references to self seem to compile okay (e.g. "self.currentFetcher 
> > = nil" or "self.pendingFetchers.remove(at: idx)"). Not sure what's special 
> > about this one.
> >
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com 
> >
> >
> > ___
> > swift-users mailing list
> > swift-users@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-users 
> > 
> >
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Zhao Xin via swift-users]

I begin to think it is related to how you `popFirst()` implemented. Check
it or post it here.

Zhao Xin

On Thu, Sep 14, 2017 at 9:36 AM, Roderick Mann 
wrote:

> Yeah, that's not it. I made the change you suggested, I get the same error.
>
> > On Sep 13, 2017, at 18:11 , Zhao Xin  wrote:
> >
> > Change `self` to `ModelFetcher`. You are calling a class static
> property, not a class instance property.
> >
> > Zhao Xin
> >
> > On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users <
> swift-users@swift.org> wrote:
> > Moving to Swift 4, I'm running into an issue for which I can't seem to
> find an answer in google:
> >
> > "Cannot use mutating member on immutable value: 'self' is immutable"
> >
> > The code looks like:
> >
> > class
> > ModelFetcher : NSObject, URLSessionDelegate
> > {
> > ...
> > static  let managerDispatchQueue=
>  DispatchQueue(label: "Model Download Manager Queue")
> > static  var pendingFetchers =
>  [ModelFetcher]()
> > static  var currentFetcher: ModelFetcher?
> >
> > class
> > func
> > startNextFetcher()
> > {
> > self.managerDispatchQueue.async
> > {
> > guard
> > self.currentFetcher == nil,
> > let mf = self.pendingFetchers.popFirst()
> >   ^ error:
> cannot use mutating member on immutable value: 'self' is immutable
> > else
> > {
> > return
> > }
> >
> > self.currentFetcher = mf
> > mf.start()
> > }
> > }
> > ...
> > }
> >
> > This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a
> monolithic app (the error shows up when this code is factored into a
> framework). Other mutating references to self seem to compile okay (e.g.
> "self.currentFetcher = nil" or "self.pendingFetchers.remove(at: idx)").
> Not sure what's special about this one.
> >
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com
> >
> >
> > ___
> > swift-users mailing list
> > swift-users@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
> >
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Roderick Mann via swift-users]

Yeah, that's not it. I made the change you suggested, I get the same error.

> On Sep 13, 2017, at 18:11 , Zhao Xin  wrote:
> 
> Change `self` to `ModelFetcher`. You are calling a class static property, not 
> a class instance property.
> 
> Zhao Xin
> 
> On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
>  wrote:
> Moving to Swift 4, I'm running into an issue for which I can't seem to find 
> an answer in google:
> 
> "Cannot use mutating member on immutable value: 'self' is immutable"
> 
> The code looks like:
> 
> class
> ModelFetcher : NSObject, URLSessionDelegate
> {
> ...
> static  let managerDispatchQueue=   
> DispatchQueue(label: "Model Download Manager Queue")
> static  var pendingFetchers =   
> [ModelFetcher]()
> static  var currentFetcher: ModelFetcher?
> 
> class
> func
> startNextFetcher()
> {
> self.managerDispatchQueue.async
> {
> guard
> self.currentFetcher == nil,
> let mf = self.pendingFetchers.popFirst()
>   ^ error: cannot use 
> mutating member on immutable value: 'self' is immutable
> else
> {
> return
> }
> 
> self.currentFetcher = mf
> mf.start()
> }
> }
> ...
> }
> 
> This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a monolithic 
> app (the error shows up when this code is factored into a framework). Other 
> mutating references to self seem to compile okay (e.g. "self.currentFetcher = 
> nil" or "self.pendingFetchers.remove(at: idx)"). Not sure what's special 
> about this one.
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 


-- 
Rick Mann
rm...@latencyzero.com


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Roderick Mann via swift-users]

Did this change in Swift 4?

I like being able to refer to the class in a class func as "self". If I ever 
change the name of the class, or refactor the code, or something, I don't have 
to change it in a bunch of places.

> On Sep 13, 2017, at 18:11 , Zhao Xin  wrote:
> 
> Change `self` to `ModelFetcher`. You are calling a class static property, not 
> a class instance property.
> 
> Zhao Xin
> 
> On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
>  wrote:
> Moving to Swift 4, I'm running into an issue for which I can't seem to find 
> an answer in google:
> 
> "Cannot use mutating member on immutable value: 'self' is immutable"
> 
> The code looks like:
> 
> class
> ModelFetcher : NSObject, URLSessionDelegate
> {
> ...
> static  let managerDispatchQueue=   
> DispatchQueue(label: "Model Download Manager Queue")
> static  var pendingFetchers =   
> [ModelFetcher]()
> static  var currentFetcher: ModelFetcher?
> 
> class
> func
> startNextFetcher()
> {
> self.managerDispatchQueue.async
> {
> guard
> self.currentFetcher == nil,
> let mf = self.pendingFetchers.popFirst()
>   ^ error: cannot use 
> mutating member on immutable value: 'self' is immutable
> else
> {
> return
> }
> 
> self.currentFetcher = mf
> mf.start()
> }
> }
> ...
> }
> 
> This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a monolithic 
> app (the error shows up when this code is factored into a framework). Other 
> mutating references to self seem to compile okay (e.g. "self.currentFetcher = 
> nil" or "self.pendingFetchers.remove(at: idx)"). Not sure what's special 
> about this one.
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 


-- 
Rick Mann
rm...@latencyzero.com


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Roderick Mann via swift-users]

Also, it works fine at a couple of other call sites. Why is this one special?

> On Sep 13, 2017, at 18:11 , Zhao Xin  wrote:
> 
> Change `self` to `ModelFetcher`. You are calling a class static property, not 
> a class instance property.
> 
> Zhao Xin
> 
> On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
>  wrote:
> Moving to Swift 4, I'm running into an issue for which I can't seem to find 
> an answer in google:
> 
> "Cannot use mutating member on immutable value: 'self' is immutable"
> 
> The code looks like:
> 
> class
> ModelFetcher : NSObject, URLSessionDelegate
> {
> ...
> static  let managerDispatchQueue=   
> DispatchQueue(label: "Model Download Manager Queue")
> static  var pendingFetchers =   
> [ModelFetcher]()
> static  var currentFetcher: ModelFetcher?
> 
> class
> func
> startNextFetcher()
> {
> self.managerDispatchQueue.async
> {
> guard
> self.currentFetcher == nil,
> let mf = self.pendingFetchers.popFirst()
>   ^ error: cannot use 
> mutating member on immutable value: 'self' is immutable
> else
> {
> return
> }
> 
> self.currentFetcher = mf
> mf.start()
> }
> }
> ...
> }
> 
> This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a monolithic 
> app (the error shows up when this code is factored into a framework). Other 
> mutating references to self seem to compile okay (e.g. "self.currentFetcher = 
> nil" or "self.pendingFetchers.remove(at: idx)"). Not sure what's special 
> about this one.
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 


-- 
Rick Mann
rm...@latencyzero.com


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users