It doesn't matter what PL devs think. The problem is that potential users believe it, even ones who should know better. What better benchmarks are out there to point people to?
That would be inconsistent with the Swift program I pointed at, which uses classes rather than malloc/free (and which as I said performs better than C if you do that). Only the #8 programs (like the one I posted) are supposed to be transliterated from C and as you can see, they accept other implementations. In fact it may be that my colleague just seized on this one example where Swift looks really slow
It's a little bothering that the intuitive way to write Swift code produces non-performant code. When I look how performant code is implemented in Swift, there seems to be always unsafe pointers behind the scenes.
I'm hopeful that Span and friends will start to change that
I find it a bin unconscionable that Span is being introduced without Swift ever having fixed the mutating slice CoW problem, especially because we know how to do it. The most intuitive way to get a view onto a portion of a collection is always going to be to slice it, and while—across resilience boundaries—there are always going to be overheads associated with slices that don't exist for Span, it's reasonable to assume that those overheads could be optimized away for many common uses of slices. The use of Span means either bifurcating generic code into that which can handle contiguous storage, or switching dynamically to different implementations, neither of which I would call “intuitive” or natural. Those kinds of gymnastics are fine for standard library jocks and experts who want to squeeze the last cycle out of their code, but simple, naturally-written code should be performant in Swift, and requiring a special facility—that you have to know to apply, and that only applies sometimes—in order to get performance fails to deliver on Swift's promise. It's in the name, people.