[fluffybucktsnek]

But these compilation times optimizations don't significantly undermine the other goals. Given that we're talking about std::span<T>, a pretty small template all things considered, I think practical evidence (e.g. actual cases) of impact is needed.

[drivebyhooting]

The problem is not the size of the span template, it’s putting whatever logic into a header file instead of a sealed compilation unit.

In a void* function prototype, whatever network code or gnarly dependency is all shielded behind a compilation unit. If you make it a template function the compiler will have to (re)process a lot of code. You could make the interface templatized in a header file and have the actual implementation use void * or char * pointer. That would recover good compiler performance.

I don’t think span provides much if any safety for the implementer of the library function. I’m also not convinced it’s more ergonomic for the caller.

[fluffybucktsnek]

You don't have to make function templated to use span. Given:

  void DoSomething(void* p, size_t numBytes);

Presuming p to mean a buffer of bytes, the direct declaration equivalent using span would be:

  void DoSomething(std::span<std::uint_8> /* or std::span<char> */ p);

No templated logic in header files necessary. The only template instantion is std:span, which, in theory, should already be used in most files. The author argues this still makes the code more complex, because of the need of reinterpret_cast, but does it actually?

std::span provides multiple ways of safely accessing data. For one, it provides an contiguous iterator, so you get access to the algorithms library basically for free. Second, you get safer accessors to the data inside, such as at, and even [] can be protected through contracts. Finally, even if you don't care about/can use these features, tying the pointer and length together reduces chances for variable confusion.

[throwaway27448]

It is, however, more readable and maintainable.