It Can Happen to You

Post by saagarjha » Thu, Mar 04, 2021, 11:38 AM UTC

adamzegelin wrote: post #111

eternalban wrote: post #92

Earlier quoted context omitted.

You can fault the docs but what's the problem with the API? Why should you be surprised that accessing a collection with 'nil' index is a runtime error? What else could it be? A simple fix in the doc seems to solve the confusion: "Returns an index that is the specified distance from the given index, unless that distance is beyond a given limiting index [in which case it returns nil]". It does say "returns an index ..…

The problem is that `s.index` with an `offset` equal to `limitedBy` returns non-nil index, rather than nil, but that index is invalid (out of bounds) and causes the program to blow up... let s = "Swift" print(s.index(s.startIndex, offsetBy: 4, limitedBy: s.endIndex)) print(s.index(s.startIndex, offsetBy: 5, limitedBy: s.endIndex)) print(s.index(s.startIndex, offsetBy: 6, limitedBy: s.endIndex)) outputs: Optional(Swif…

Post by saagarjha » Thu, Mar 04, 2021, 11:48 AM UTC

bzbarsky wrote: post #116

eternalban wrote: post #92

Earlier quoted context omitted.

You can fault the docs but what's the problem with the API? Why should you be surprised that accessing a collection with 'nil' index is a runtime error? What else could it be? A simple fix in the doc seems to solve the confusion: "Returns an index that is the specified distance from the given index, unless that distance is beyond a given limiting index [in which case it returns nil]". It does say "returns an index ..…

If s.index() returned nil, the "if" would test false and the s[i] would not be reached. The problem is that it returns non-nil, but the _limit_ is broken in this case: using s.endIndex as a limit means you can get non-nil but bogus indices returned. And yes, this is the fault of the docs for using a broken last arg to the API, but there's no really clean way to use this API as designed, afaict. At least not if you wa…

  let s = "Swift"
  if !s.isEmpty,
      let index = s.index(s.startIndex, offsetBy: 5, limitedBy: s.index(before: s.endIndex)) {
    print(s[index])
  }

Post by saagarjha » Thu, Mar 04, 2021, 11:56 AM UTC

sjburt wrote: post #25

rectang wrote: post #2

Pro tip: the classic recursive approach to implementing the Fibonacci sequence exhibits eye-wateringly poor performance.

I've always hated how that's used as an example of recursive programming in early programming education. Invariably, students try a large n, get a stack overflow and conclude that recursion is inefficient, leads to mysterious errors, and must be avoided.

Post by lloeki » Thu, Mar 04, 2021, 12:03 PM UTC

toyg wrote: post #266

TeMPOraL wrote: post #199

Earlier quoted context omitted.

You're joking, but now I'm thinking about the XML we parse at work and the library we're using to do it. We parse a lot of it, but I've always had this vague feeling that it takes a bit too long (given the codebase is C++). The XML library we use is rather well-known, so if someone found a bug like this there, I'd suspect a general improvement of performance across the board in the entire industry. Efficient Market H…

> it's unlikely the library has this problem Any sufficiently-complex library code likely has plenty of problems, often unavoidably so (e.g. trade-offs between best performance and edge cases). Whether they have been found or not is a function of many, many factors. > Efficient Market Hypothesis I've lived long enough to be very sceptical about that sort of thing. Markets tend to be efficient in aggregate , maybe, bu…

Post by layer8 » Thu, Mar 04, 2021, 12:05 PM UTC

Gibbon1 wrote: post #256

ajkjk wrote: post #153

Earlier quoted context omitted.

Obligatory: it is flabbergasting that this is a quality of language that is still in active use.

It's even more flabbergasting that all these problems haven't been fixed.