What I was trying to say was that it would be nice to have zero runtime overhead---if at all possible. As I understand from your answer, this library will effectively translate the convenience syntax to WS... calls at runtime, not at compile time. There is extra code that runs when using this library, that would be avoided if using WS... functions directly. I am not sure about the feasibility of all compile time solution.I may work to some extent but there are scenarios that are difficult to tackle this way. Given a very simple use case List[1, 2, 3, 4] // mathematica syntax A similar C++ syntax List<1, 2, 3> which build the WS call chain on compile time, but it is not possible to pass string in this way. A syntax like a = List(1, 2, 3, "hallo") can builds the call chain at compile time. But a scenario like the following a = List(); // empty List initiated for (auto x: l){ a.arg(x); } expecting to build a List (not append) at the end of the loop requires a runtime storage for the call chain. Otherwise if it entirely built on templates some more magic like b = arg(a, x) can be used to abandon a and generate a new b. i.e. once an object is created it wont be mutable. Whether it is a good design or bad design is a matter of debate and depends on use case. I am not very much sure about such feasibility. And I am afraid that things may turn ugly. I thought about this for quite a while and decided to store and populate it on runtime with delayed callbacks. Even if I generate the call chain on compile time there will be some wrapper around the WSTP functions. That part is unavoidable. The only extra overhead is the runtime storage of the call chain. Each delayed call ftor requires few words. So for the second part of your question, yes there is an extra code that is running but I don't consider it as a bottleneck. This is however very inefficient when working with numerical arrays, a very common task in scientific programming Yes then there needs to be case by case exception in the fetch call. However the problem is while fetching the library knows that it is fetching a List . But the library doesn't know that it is fetching a list of all 64 bit integers. While making Put calls the exceptional rules may still work but for Get calls I am not sure about its feasibility. The problem is that if one decides to write a program that runs in a separate process and communicates with the kernel through MathLink, one does have the option to choose either MathLink (ML prefix) or WSTP (WS prefix), or switch between the two with the preprocessor technique you mentioned. However, when using LibraryLink, which is usually a better option than installable MathLink programs, one must use MathLink (ML-prefix functions). Thus basing such a library on the wstp.h header will limit its usability (no LibraryLink). Basing it on mathlink.h wouldn't. I don't think there is any benefit criticizing wolfarm's decision in this regard this is what is happening for few years. It doesn't seem to go in the ML direction in future. So I targeted with WSTP only. However I kept all low level (WS) calls in few places so that it never turns hectic to change from WS to ML. Currently I am busy for an week. I'll see if I can push that change in few days.