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] noob question about modules

[blaster_in_black via swift-users]

For the record, I will paste here the answer I have received on StackOverflow. 
It adds some useful tips to the info provided by Alex. In short,

Swift modules are somehow equivalent to Java packages, and Swift frameworks to 
Java .jars (if we don't get too formal);
Swift (sub)modules can be visible to clients and the latter can import them 
much as Java sub-packages are imported;
Swift (sub)modules are not implicitely defined by the source code folders 
layout, but by meta-files and tooling that are external to the source code 
(contrarily to Java).

https://stackoverflow.com/questions/46228517/swift-submodules-what-are-they-exactly

Cheers,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: Re: [swift-users] noob question about modules
> Local Time: 14 September 2017 12:26 PM
> UTC Time: 14 September 2017 10:26
> From: swift-users@swift.org
> To: alb...@apple.com
> swift-users@swift.org
>
> Thanks much, Alex.
>
> But how do you physically partition the namespace within a module, if not by 
> sub-folders?
>
> I am not sure whether the following example is, by definition, of a submodule 
> that one could import by writing "import Cacao.StyleKit":
>
> Https://github.com/PureSwift/Cacao/tree/master/Sources/Cacao/StyleKit
>
> Sent from ProtonMail mobile
>
>  Original Message 
> On 13.09.2017, 10:23, Alex Blewitt < alb...@apple.com> wrote:
>
>> No, submodules in Swift bear little relation to sub packages in Java. It's 
>> really just a way of partitioning the namespace within a single module. Nor 
>> is there any relation between the path and the name of the module either.
>>
>> Alex
>>
>>> On 12 Sep 2017, at 22:41, blaster_in_black via swift-users < 
>>> swift-users@swift.org> wrote:
>>>
>>> Hi,
>>>
>>> I am beginning with Swift 4 (coming from the Java world) but I do not have 
>>> yet a Swift development environment to experiment with. Therefore my 
>>> question(s) might sound a bit silly. Unfortunately, I haven't been able to 
>>> answer them by reading the online Language Guide.
>>>
>>> 1) What makes a submodule? I can see online examples about how to import 
>>> them, but not how to create one or any other further details about them. 
>>> Are they like Java packages inside a jar? Do their hierarchical name ( 
>>> prefix1.prefix2. ... .submodulename) reflect a path tree on the filesystem 
>>> (/ prefix1/prefix2. ... /submodulename), just as it happens with Java 
>>> packages?
>>> 2) Can two different submodules within a single module export two different 
>>> classes under a single class name? Like  module.submodule1.MyType and 
>>> module.submodule2.myType.
>>>
>>> Thanks in advance.
>>>
>>> David
>>>
>>> ___
>>> 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