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

[swift-users] TWISt-shout Newsletter 2017-09-18

[Kenny Leung via swift-users]

Hi All.

Here is your TWISt-shout Newsletter for the week of 2017-09-11 to 2017-09-17

https://github.com/pepperdog/TWISt-shout/blob/master/2017/TWISt-shout-2017-09-18.md
 


Enjoy!

-Kenny

___
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] Generics with Protocols - Separate files

[somu subscribe via swift-users]

Sorry about the typo (filenames for the code were mentioned wrong).

The corrected filenames are as follows (problem still occurs):

Question:
- Why does the error occur when extension CarID : P2 {} is defined in 
CarID.swift ?


CreateCars.swift:

import Foundation

protocol P1   {
associatedtype ItemID
}

class Car : P1 {
typealias ItemID = CarID
}

//extension CarID : P2 {} //Error wouldn't occur if this line is uncommented 
and the line in CarID.swift is commented out

protocol P2 {}

class CreateItems
where Something.ItemID : P2 {}

class CreateCars : CreateItems {} //Error: Type 'Car.ItemID' (aka 'CarID') 
does not conform to protocol 'P2'

extension CreateCars {}



CarID.swift:

import Foundation

class CarID {}

extension CarID : P2 {} //If this line is moved to CreateCars.swift the error 
vanishes away


Thanks and regards,
Muthu





> On 17 Sep 2017, at 10:55 AM, somu subscribe via swift-users 
>  wrote:
> 
> Hi,
> 
> When using Generics with Protocols I get a compilation error depending on 
> whether or not conformance to a protocol is defined in the same file or not.
> 
> Error: 
> Type 'Car.ItemID' (aka 'CarID') does not conform to protocol 'P2'
> 
> I have 2 swift files:
> - CarID.swift
> - CreateCars.swift
> 
> Observations:
> - I get the error when extension CarID : P2 {} is defined in CarID.swift
> - I don’t get the error when extension CarID : P2 {} is defined in 
> CreateCars.swift as shown in the comments below.
> 
> Tested On:
> - Xcode 9.0 (9A235) - GM
> - Command Line project / iOS project
> 
> 
> CarID.swift:
> 
> import Foundation
> 
> protocol P1   {
> associatedtype ItemID
> }
> 
> class Car : P1 {
> typealias ItemID = CarID
> }
> 
> //extension CarID : P2 {} //Error wouldn't occur if this line is uncommented 
> and the line in CarID.swift is commented out
> 
> protocol P2 {}
> 
> class CreateItems
> where Something.ItemID : P2 {}
> 
> class CreateCars : CreateItems {} //Error: Type 'Car.ItemID' (aka 
> 'CarID') does not conform to protocol 'P2'
> 
> extension CreateCars {}
> 
> 
> 
> CreateCars.swift:
> 
> import Foundation
> 
> class CarID {}
> 
> extension CarID : P2 {} //If this line is moved to CreateCars.swift the error 
> vanishes away
> 
> 
> Thanks and regards,
> Muthu
> ___
> 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 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