Jeremy, if you're up for it, could you talk any more about your explorations of Julia?

I see (and agree with) your point about worse non-numeric stuff, but if you stand back and squint I get the impression Julia does most of what you applaud here, with the added benefits of a more transparent compiler and a more numeric-focused community (no need for BasicMath there!).

In particular, Flux.jl seems like a fairly direct competitor of S4TF, and this blogpost [0] really blew me away.

[0] https://www.julialang.org/blog/2018/12/ml-language-compiler

Interesting article, but I have one nit. I don't think your reasoning behind why Objective C does not support overloading is sound. Selectors are completely incompatible with C function names anyway. For example, they are only relevant in the context of classes (which do not exist in C), or example they allow characters that are illegal in C function names in symbols (like ':').

The bigger issue is that to overload a function in a manner similar to C++ you need to have accurate type information, which historically was not available in Objective C since it relies heavily on duck typing and casting objects back through id. If such strong type information was available then the type data could have simply been mangled into the selector by the compiler the same way it is mangled into the symbol name in C++. I suspect that duck typing allowed a lot of productivity and memory wins in the 90s, and that most compilers of the era were not capable of exploiting the strong typing information to optimize as aggressively as they do now, meaning that it was probably the right trade off for the time.

I suppose an alternative implementation of overloading could have been implemented by having objc_msgSend dynamically query the types of all parameters which are overloaded, but that would have resulted in a huge performance hit on every dynamic message dispatch.

Curious if you ever benchmarked your approach vs, say, going through `Array`/`ContiguousArray` (I think these are slated to converge eventually, FWIW) and using the [`withUnsafeMutableBufferPointer(_:)`](https://developer.apple.com/documentation/swift/array/299477... calls?

You've gotten into a place with a lot of unidiomatic designs--direct pointer access on COW types, etc.--and it's not clear how much is really necessary:

    extension Array where Element:CanDoMath {
    
      // instead of this style:
      func sum_outside() -> Element {
        var result = 0
        let p = self.pointerToStorage // your "get the pointer" method, I think it was just `p`, too?
        for i in 0..<count {
          result += p[i]
        }
        return result
      }

      // how does this compare (in -unchecked mode, at least)?
      func sum_inside() -> Element {
        return self.withUnsafeBufferPointer() {
          var result = 0
          for v in $0 {
            result += v
          }
          return result
        }
      }
    }

For (b) if you're planning to call things that need particular alignments then as far as I know you will need to write your own storage at this time.