parens braces semicolons operator overloading generics etc

the lack or presence of these things are never deal breakers, it can be worth trying to adjust because maybe you will find 900 things you love about the new way that make up for the one or two things you think you can’t stand.

Again, the language is great. It's a young project. I'm glad you like it. Andrew seems to have a very firm idea of where Zig is headed. It's just not for me, in part because operator overloading is not a "little thing" for me.

Sure, but it can definitely break a tie. Frankly, operator overloading can create some really nice apis. And code that's pleasing to read takes less mental overhead to pick up.

    eval("Ax + v", {.A = …, .x = …, v = …})

I'm a bit sad there seems to be no interest in adding interpolation syntax to Zig. While anonymous tuples work well for shorter expressions, they can get confusing for larger textual templates or DSLs, imo.

I've been experimenting with Zig for WASM, for example, and the readability of HTML templates suffers. I'd love to be able to pass arguments inline, and while we can do that with anonymous tuples, the added noise makes it annoying to use in practice. I believe Javascript's template literals, out of all things, would be a fitting inspiration for a little syntactic sugar on top of anonymous tuples:

  var tuple_params = html.create("{} ... {} ... {}", .{a, b+c, observable});
  
  var tuple_inline = html.create(.{"", a, " ... ", b+c, " ... ", observable, ""});
  
  // equivalent to tuple_inline
  var tuple_sugar = html.create(`{a} ... {b+c} ... {observable}`);

  var tuple_params = html.create("{[foo]} ... {[bar]} ... {[observable]}", .{
    .foo = a,
    .bar = b+c,
    .observable = observable,
  });

OK, but how much code is it? I doubt even a game engine has matrix operations in more than 0.1% of its lines of code (obviously, in Matlab/Julia it can by 99%). The beauty of so little code is a worthy sacrifice for the explicitness of a low-level language.

I like Zig overall, but lack of operator-overloading just seems like a pain to me.

Zig in many ways puts faith in the coder to not screw things up, but in this case it diverges from that philosophy. Would it be too much to trust the user not to overload operators in an unacceptable way? Social convention over technical constraint.

That said I'd be more persuaded by the argument that it's not worth the extra code and complexity for a language as concise as Zig.

It is a pain, but all things considered, having it would have been a greater pain. Note that the main issue with operator overloading in Zig isn't so much the operator part but the overloading part, because overloading introduces ambiguity that cannot be resolved at the code-unit level. Zig doesn't allow name overloading even for ordinary identifiers (actually, Zig is more strict in its opposition to overloading than Clojure or Erlang, which do allow it when there can be no ambiguity). I think it's more likely that Zig will allow user-defined infix operators (say +' or something) before it allows overloading of any kind.

> Zig in many ways puts faith in the coder to not screw things up

I understand Zig very differently. Zig puts a lot of effort to make it hard for the coder to screw up. Even where it doesn't enforce correctness at compile time or at runtime (and it does both much more than C++, to the point that the goal is to eliminate all or nearly all undefined behaviour in safe mode), its strong emphasis on correctness, including functional correctness, is expressed precisely through a simple and lean language that's easy to understand, so that it's harder for the programmer to screw up (plus fast compilation and easily isolated code units). So to the extent that Zig puts faith in the coder (less than C++, more than Rust), it can do so because the language is so lean and simple.

I proposed this and it got rejected by the language committee.

Can you explain this a bit? Operator overloading just seems like such a strange bugbear of Zig folks to me. Maybe I've just never been bitten by it, but at least in Elixir, my main language, I've never really understood the danger.

Are operators truly so different from functions? You'd expect that any function you import could do, well, anything. Aren't operators essentially just the same thing, just with a "prelude" in the language that basically imports them by default?

In Elixir, you might have (discouraged):

    defmodule MyMod do
      import MyOperators

    defmodule MyMod do
      import MyOps, only: [+: 2]

> The very concept of operator overloading is incompatible with such a guarantee.

Why would operator overloading allocate memory? The memory is already allocated(by the user) when you call with the operands.

What if I wanted to overload the + operator to concatenate strings?

There is definitely some merit in being puritanical about not having any allocations in operators.

Not operator overloading; just overloading. You can't overload ordinary-named subroutines in Zig either.

> and then you know plus (with two arguments) has a different meaning in that module.

That's not overloading, that's shadowing. Overloading is when the same name refers to multiple things depending on the type of its arguments. Erlang allows overloading based on arity, but that's something that can be understood from the call-site code.

This seems clearly false to me. Operator overloading is non-virtual type-based dispatch, just like the dot operator for method calls in C++/Java/etc., and is resolved statically at compile time. You can think of overloadable "+" as just syntactic sugar for an ".add()" method (in fact, this is more or less exactly how it's implemented in Rust). Even if your language doesn't have methods, you can implement overloading with typeclasses, like Haskell does (as does Rust, formally speaking).

We could certainly argue on whether disallowing overloading is helpful, but it's first important to understand what the principle is, and it's not about the operators.

No, it doesn't. Knowing what function "+" resolves to requires only the type of the left-hand side (or, I think, the RHS as well in Haskell). Absent overlapping instances (which Rust doesn't support, and Haskell only supports with an extension), there can only be one such function implementation per type. And, since top-level items are fully type-annotated in Rust (and idiomatically annotated in Haskell), this is a completely local determination. Therefore, for every occurrence of "+" in the source, it's completely unambiguous which implementation "+" calls, and this can be determined solely by looking at the calling function.

The end result: Rust, like Zig, disallows overloading of names, but Rust also effectively supports overloaded operators via traits (typeclasses).

Right, and that's more than one definition per name. In Zig, a name refers to only one definition. (Plus, recall that in Zig the type of a target isn't always known when reading the code, probably more frequently than in C++ or Rust, where this only happens in macros.)

> disallows overloading of names

That the definition referred to by an identifier depends on the type is what overloading means. Overloading is the very essence of traits.

> in C++ or Rust, where this only happens in macros

Sorry, this is wrong. In both of these languages it happens much more frequently. All the time, in fact, whenever you either infer return types or just chain calls on return values, or when the type is a generic/template type parameter. So when you see `foo(e)` or `e.foo()`, where `e` is some expression, you can only tell which definition of `foo` is referenced -- or even whether two instances of `foo` refer to the same definition or not -- by figuring out the type of `e`, which is often implicit in the code.

> Overloading is the very essence of traits.

Which is why in Zig, the mechanisms that perform a similar task to that of traits -- i.e. abstracting over types -- work differently, without overloading.

As a general rule, Zig does not want the semantics of a piece of code to depend on things the compiler might know but the reader of the unit might not. Whether or not such a degree of explicitness is a worthy principle for a low-level language is a matter of taste, I suppose.

https://github.com/ziglang/zig/issues/7305

https://www.godbolt.org/z/zWGfcY5a4

Whether this code translates to SIMD or scalar operations under the hood should depend on the target platform and compiler options.

Say you have this (pseudocode):

    function foo() {
        let bar = make_bar();
        defer cleanup_bar(bar);
        let baz = make_baz();
        defer cleanup_baz(baz);
        let quux = make_quux();
        defer cleanup_quux(quux);

        do_something_with(bar, baz, quux);
    }

So you decide to DRY by moving the creation to a common function.

    function create_mocks() -> (Bar, Baz, Quux) {
        let bar = make_bar();
        defer cleanup_bar(bar);
        let baz = make_baz();
        defer cleanup_baz(baz);
        let quux = make_quux();
        defer cleanup_quux(quux);

        (bar, baz, quux)
    }

You could fix this by switching to a callback approach:

    function run_with_mocks(f: function(Bar, Baz, Quux)) {
        let bar = make_bar();
        defer cleanup_bar(bar);
        let baz = make_baz();
        defer cleanup_baz(baz);
        let quux = make_quux();
        defer cleanup_quux(quux);

        f(bar, baz, quux)
    }

Worse, if not all tests use the same mocks, you actually end up with multiple of these functions:

    function with_bar(f: function(Bar)) {
        let bar = make_bar();
        defer cleanup_bar(bar);

        f(bar)
    }

    ...

    function foo() {
        with_bar(bar => {
            with_baz(baz => {
                with_quux(quux => {
                    do_something_with(bar, baz, quux);
                });
            });
        });
    }

Instead you'd return an object, and make it the callers responsibility to close it. Destruct all three in the close call.

It may not fit your mental model, and that's fine. But let's not pretend it's a serious hurdle.

No, it's not a psychological problem. This is real complexity, and it's one of the most serious and widespread issues in software development.

The key issue is that we often have rules that say: Whenever A happens then B must happen as well. It is absolutely critical that rules like this are expressed in exactly one place and that enforcement is opt-out not opt-in.

Everything else is error prone and creates significant mental burden.

Go doesn't have generics so you can't really do this, but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront, make_ functions that return the pre-initialized stuff, followed by running the function, followed by no-op deinits, followed by whatever forensics you'd like to run later.

This is missing the point. The point of a destructor is that it runs automatically. .deinit() is the same as the three cleanup_*()s in my example and thus has the same problems.

>but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront

The third example in my post shows why this is inadequate.

Have you tried doing what you propose in zig? Ultimately, the only difference between a .deinit() and a destructor is that one is explicit and the other is not. There are cases where you can easily make a mistake for both an explicit destructor and an implicit destructor.

it does in zig:

    fn create_mocks() !struct {bar: Bar, baz: Baz, quux: Quux} {
        var bar = try make_bar();
        errdefer cleanup_bar(bar);
        var baz = try make_baz();
        errdefer cleanup_baz(baz);
        var quux = try make_quux();
        errdefer cleanup_quux(quux);

        return .{
            .bar = bar,
            .baz = quux,
            .quux = quux,
        };
    }

    func make_foo() *Foo {
      return &Foo {
        bar: make_bar(),
        baz: make_baz(),
        quux: make_quux(),
      }
    }
    func cleanup_foo(foo *Foo) {
      cleanup_bar(foo.bar)
      cleanup_baz(foo.baz)
      cleanup_quux(foo.quux)
    }

    // elsewhere
    foo := make_foo()
    defer cleanup_foo(foo)
    // [rest of logic goes here]

Poor man's:

    func make_foo_with_mock_bar() *Foo {
      return &Foo {
        bar: make_mock_bar(),
        baz: make_baz(),
        quux: make_quux(),
      }
    }

    func make_foo(bar: Bar, baz: Baz, quux: Quux) *Foo {
      return &Foo {
        bar: bar,
        baz: baz,
        quux: quux,
      }
    }

Even if you have reservations about where verbosity lies, I don't see how this affects the cleanup side.

So if bar, baz, quux aren't intrinsically related as a unit and might be mixed and matched arbitrarily, you just forego the whole ceremony and call each thing or the respective mock individually (the argument being that if you're making multiple different permutations, you're not repeating yourself per se; e.g. mocks don't need to be cleaned up in the first place)

There's also something to be said about tests needing several arbitrary mocks. Normally, I'd consider that a smell. I've actually seen the pattern of making a kitchen sink foo for scenarios like that, but with nils/noops for unused things (can't say I like that approach though).

(https://smartlogic.io/podcast/elixir-wizards/s6e6-matthias-l...) if you're curious

With the three mocks I gave, there are 2^3 - 1 = 7 possibilities of which mocks a particular test needs. Of these, three are degenerate cases of a single mock each which would be served by the individual make_* already, so that leaves four cases of make_foo* that you'd need to implement.

With more than three mocks, this number grows rapidly.

    func newMocks(
    ) (
      foo Foo, bar Bar, baz Baz, 
      cleanup func(),
    )

You could just make a function that creates all the mocks needed for all tests, but you don't like that. So the only option left is to specify which mocks you need for each test... which is exactly what the original code is doing.

You're running into a wall because you're trying to abstract code that's already maximally abstracted.

One upside of destructors is that adding destructor cleanup to a type isn't necessarily a breaking change. (In Rust terms, as long as the type isn't "Copy".) But in languages with defer or with/using statements, it is.

Another upside of destructors is that the cleaned-up state can be mostly hidden from other code. But when cleanup is a regular function, it's easier to access an object after cleanup, and you have to reason more about what happens in that case. (A Rust example here might be "What happens if you use a Box after it's freed?" The answer is that you just can't do that, even though Box doesn't have a freed/null state.)

But I get your point: with destructors you are free to change the ownership responsibilities, because the link between a variable and its releasing is implicit and carried over by the runtime, instead of explicitly being cared for by the code.

With the C++ destructor RAII pattern I can use it at any lexical scope I need it at, which is super handy.

it is way too easy to critique an approach that led to a problem that hasn't happened to you, and is described to you by someone else.

Your initial pretense was that you always make 3 objects, so move it into a function.

When people show how to accomplish that, you state 'well what about my test that doesn't need all three?'

Why are you testing things your code doesn't do?

You've phrased this as if I said this after I'd been given a solution for the initial problem. In reality, I mentioned this in the original post itself, but it seems many people didn't read it.

It's almost like I have prior real-world experience of this problem, where I already went down the path of making common functions for all the creation and cleanup respectively, only to find that it doesn't help when all the functions don't create the same subset of things.

>Why are you testing things your code doesn't do?

I have no idea how you came to this conclusion.

I've been a Go mentor for years, and see how people take concepts they are used to and try to shoehorn them in, and complain they are ugly.

In this case, when I first saw your examples, my thought was 'youre doing it wrong'. But not wrong as in incorrect, but now how the language was designed.

If you truly care we can go through scenarios and I can tell you how I'd approach it. But in my past experience, when people find a paradigm they like, they tend to not listen.

I think people have a bias against destructors because of C++, but they really are pretty nice. Speaking as a guy that uses C instead of C++, destructors are the one thing I would add to C.

It's understandable why a language trying to be close to C in spirit does not have them.

It does make things much easier.

And you can call close like: file.close().await.unwrap(); https://github.com/tokio-rs/tokio-uring/pull/17/files#diff-b...

  try std.fs.cwd().openFile(path, .{}) |file| : file.close()
  {
    // ... code ...
    // file.close() is called at the end
  }

    {
        var file = try std.fs.cwd().openFile(path, .{});
        defer file.close();

        // ... code ...
        // file.close() is executed here
    }

  try std.fmt.allocPrint(allocator, "problems/{}", .{ id }) |path| : allocator.free(path) {
    try std.fs.cwd().openFile(path, .{}) |file| : file.close() {
      try file.stat() |stat| {
        try allocator.alloc(u8, stat.size) |contents| : allocator.free(contents) {
          // do something with 'contents'
        }
      }
    }
  }

  const path = try std.fmt.allocPrint(allocator, "problems/{}", .{ id });
  var file = try std.fs.cwd().openFile(path, .{});
  const stat = try file.stat();
  var contents = try allocator.alloc(u8, stat.size);
  defer allocator.free(contents);
  defer file.close();
  defer allocator.free(path);