[drivebyhooting]

It’s this kind of attitude that perpetuates bad compilation time.

Templates have to get parsed and instantiated over and over again. Then you need link time optimization to deduplicate all the redundant copies of the same code.

[pjmlp]

No they don't, modules exist, as do external template libraries.

[fluffybucktsnek]

If youif you are using C++, your last concern will be compilation times. By this point, just use C.

[drivebyhooting]

Untrue. Lots of effort is spent optimizing compilation time at big FAANG companies. And there a lot of established techniques for creating “compiler firewalls” and explicitly instantiating templates once.

[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.

[throwaway27448]

It is, however, more readable and maintainable.

[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.