> 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 <swift-users@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 rm...@latencyzero.com _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
