Zig-style generics are not well-suited for most languages

- Values dependent on values (algorithms)

- Values dependent on types (parametric polymorphism)

- Types dependent on types (type-level functions)

This is one dimension weaker than Calculus of Constructions (CoC) [1], which permits types dependent on values (so-called "dependent types"), but we don't need them until we want to prove some properties about our code (dependent types correspond to logical predicates). Some tasks handled by metaprogramming however may not be handled even by a type system that permits type-level functions; for this reason, probably we have to include some sort of simple syntax transformations, such as those found in Idris [2].

I expatiated in one of my posts [3] on why static languages duplicate their language concepts. This writing also includes Zig and Idris.

[1] https://gist.github.com/Hirrolot/89c60f821270059a09c14b940b4...

[2] http://docs.idris-lang.org/en/latest/tutorial/syntax.html

[3] https://hirrolot.github.io/posts/why-static-languages-suffer...

https://dlang.org/spec/template.html#template_constraints

It's simple to implement and understand, as it doesn't introduce any new syntax, and people already know how to write conventional code.

> How does Zig handle the monomorphization problem for generics in library APIs?

From the article:

> Cannot distribute binary-only libraries with generic interfaces … Zig doesn’t have this constraint because Zig is designed around whole-program compilation from the start …

So no proprietary (EDIT: (closed)) libs built with Zig, I guess.

So if I have two types, both of which can be represented by an underlying Int, but have entirely different semantics or methods (for instance, LosslessStringConvertible or various computed fields based on the underlying Int), I have to wrap the underlying type in either an enum with a single case or a struct with a single field, obscuring the meaning of the type and requiring awkward duplicate naming of the struct field/enum case.

The ExpressibleBy*Literal protocols are some help here, allowing Int/String/Array literals to be directly assigned to the type, but this only helps for assignment and not for retrieving the underlying value (and only applies when the type can be initialized from the literal without any failure cases).

It’s not a huge deal, but a simple newtype statement would make the generics system far more general and easy to use imo.

    1. The model for expressing and instantiating a generic function.

    2. The model for constraining a generic function such that type errors are as
       local and comprehensible as possible.

When people argue that Zig made the right decision for generics, and that other languages should follow suit, they are talking about #1, not #2. To convince me that "Zig-style generics are not well-suited for most languages", you would need to convince me that Zig's choice for #1 will make it difficult or impossible to do #2 later.

> Limited compiler support when calling generic code

> Limited compiler support when writing generic code

> Limited type inference

> Cannot distribute binary-only libraries with generic interfaces

> Tooling needs to do more work

> Inability to have non-determinism at compile time

> Inability to support polymorphic recursion

Why are these things not a problem in Zig?

(They probably won't be sound type constraints, but maybe that's not that big a deal, since the result would be a worse compile error at instantiation time.)

I really don't like how all of these camps have started shouting at each other. I really like both Rust and Zig and think both of their approaches are super interesting paths forward for the industry. They are both re-examining things that has been very locked in place for a long time in the industry. Zealotry on either side is super cringe.

In Zig's case it is good to look at the choices made in the type system of other languages. What do we loose and what do we gain over these? There were probably reasons why they went the way they did. Learn from it. Don't shout that our way is the best and don't assume that you were the first to find this perfect solution to all type problems. Both of those reactions are just childish.

And clearly it is only a matter of different tastes (i.e. wanting all languages to be just about the opposite of Zig/C++/D etc.): the choice of traditional compilation is ridiculed rather than understood as a deliberate and useful limitation and the worst accusation against "templates" is that they are inelegant and that they lead to messy error messages, not that they are limited.

Well, you could if you either ensure, that the layout of the inherited part of a structure is the same for all structures, that inherit the same structure. Or you could return a tagged enum. However, with interfaces or traits, you just have to ensure that the table of interface/trait-methods of different types, that implement the same interface/trait. This table is constant and therefore a reference to it can be shared by every instance of the interface/trait.

Yes, it might be slower, because instead of direct method-calls, you have a layer of indirection, but you only need one copy of the method, not one for every type-combination. If all copies of this method have to fit in the L1-cache simultaneously but cannot, it might actually be faster.

> - Require specifying what operations are possible in the function signature. These can be checked at call-sites of myGenericFunc. There are various approaches to this – Go interfaces, Rust traits, Haskell type classes, C++ concepts and so on.

> - Don’t require specifying the operations needed up-front; instead, at every call-site, instantiate the body of myGenericFunc with the passed type arguments (e.g. T = Int, S = Void), and check if the body type-checks. (Of course, this can be cached in the compiler to avoid duplicate work if one has a guarantee of purity.)

As a C++ programmer by trade, its interesting to see C++ as a language go from the 1st approach (via inheritance) to the 2nd approach (via templates). The 2nd approach feels weirdy dynamic, and it's interesting to see a return to the first approach with C++20's concepts.

A note about C++. Prior to C++20 concepts, you could always add constraints to templates via [SFINAE](https://en.cppreference.com/w/cpp/language/sfinae), it had the tendency to be verbose:

  template<typename T, typename = 
  enable_if_t<is_integral_v<T>>>
  T add_2(T x) {
      return x + 2;
  }

  struct Writer {
      virtual void write(const char *) = 0;
  };
  struct SubWriter: public Writer {
      virtual void write(const char *s) override {
          puts(s);
      }
  };

  template<typename T, typename = 
  enable_if_t<is_base_of_v<Writer, T>>>
  void write_to(T x, const char *msg) {
      x.write(msg);
  }

  int main() {
      printf("%d\n", add_2(4)); // works
      write_to(SubWriter{}, "Hello"); // works
  }

  integral auto add_2(integral auto x) {
      return x + 2;
  }

  struct Writer {
      virtual void write(const char *) = 0;
  };

  template<typename T>
  concept Writable1 = is_base_of_v<Writer, T>; // uses 
  type_traits

  template<typename T>
  concept Writable2 = requires (T t) { // uses compile time 
  requirements, similar to Go interfaces
      { t.write("Hello") };
  };

  struct SubWriter1: public Writer { // satisfies Writable1 
  and Writable2
      virtual void write(const char *s) override {
          puts(s);
      }
  };

  struct SubWriter2 { // satisfies only Writable2
      void write(const char *s) {
          puts(s);
      }
  };

  // accepts both SubWriter1 and SubWriter2
  void write_to(Writable2 auto x, const char \*msg) { 
      x.write(msg);
  }

  int main() {
      printf("%d\n", add_2(4)); // works
      write_to(SubWriter1{}, "Hello"); // works
  }

Templates in C++ are quite different because of overload candidate resolution (and so SFINAE), which makes debugging templates a pain. Zig doesn't have overloads at all, plus, the error reporting mechanism (which C++ doesn't have) is available at compile time, as it is at runtime. So Zig both has better error reporting (or the potential for that) and doesn't have a big source for scary template errors in C++ even before adding concepts.

Having said that, I actually would like to see "concepts" in Zig, probably as a simple boolean predicate as the type annotation in function parameters, for one reason, and one reason only, which isn't mentioned in the article: documentation.

BTW, there's a general trend to compare Zig to some other language and extrapolate from it, but while I understand why people think that's helpful, it ends up just being confusing, because Zig is a very radical language that's not really similar to anything (except superficially). So it's very hard to compare features in isolation, because most problems are caused by an intersection of some features, and pretty much all the interesting features in Zig are different from what people know -- some are "stronger" and some are "weaker."

> The compiler gives you more flexibility, but OTOH if you want library users to have a good developer experience when they make mistakes, you need to do a bunch of extra work.

Yes, but I'd say the difference here, while similar in argument to typed vs. untyped languages, is qualitatively different. The value of finding errors sooner is not as high as the difference between finding errors before a program runs on the user's machine or after. Even if a generic library isn't well-tested (although, any library might not be well-tested) to the point that it has simple type errors, those errors will not find their way into the executable.

Having said that, I obviously agree that Zig's type system is not for all languages, but I'm surprised the article doesn't mention one of the most obvious reasons. Most application programming these days is done in languages that are JIT compiled, and so they don't need partial evaluation (i.e. compile-time evaluation) as much as low-level programming languages do. While some low-level languages have generics/templates and macros and constexprs -- and require distribution of libraries as source code anyway -- many if not most of the popular application languages can do with just generics. Zig's system is definitely much simpler (and personally I find it more elegant) than generics+macros+constexprs, but it isn't simpler than just generics. What Zig discovered was that since low-level programming languages do require partial evaluation, it can be made general and pleasant enough to also do polymorphism (so generics aren't required) and powerful enough to not require macros (which are usually good to avoid, and often require another "language within a language"). So I'd say that if your language does require sophisticated partial evaluation, consider Zig's approach -- it's revolutionary and refreshing; if not, you're probably better off with generics.

I'm still not sure if i want to commit with zig, i don't enjoy its ergonomics and error messages (way too noisy, i have to constantly scroll), but whenever i want to implement tagged unions in C.. i just want to drop C and use something nicer

C/C++, Rust, D and even C#, they all don't have them, for C/C++ it's understandable, but for the other ones.. shame on you

> getting read of constraints

Some proofreading is in order.

    @font-face {
        font-family: system;
        font-style: normal;
        font-weight: 400;
        src: local("-apple-system"), local("BlinkMacSystemFont"), local("Segoe UI"), local("Roboto"), local("Oxygen-Sans"), local("Ubuntu"), local("Cantarell"), local("Helvetica Neue"), local("sans-serif");
    }