On: Zig and Rust

[steveklabnik]

Nothing is breaking! The change isn't a move to a zig-like style, but instead, that in today's Rust, you have

  struct Foo<T> {
      // ...
  }

and not

  struct Foo<T, A: Allocator> {
      // ...
  }

This isn't breaking because there is a default type provided for A.

The handwave is over "Today's Rust", as this machinery has already landed, in a sense, it's just not really possible to use with the standard library because the allocator API isn't fully stable.

Here's an actual example: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html See that "A = Global"?

[MrBuddyCasino → steveklabnik]

I see. I'm interested in the motivation and design goals behind it, is there something that spells those out? The only thing I could find quickly is this [0].

[0] https://internals.rust-lang.org/t/why-bring-your-own-allocat...

[steveklabnik → MrBuddyCasino]

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.

My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators

The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

[throwawaymaths → steveklabnik]

what if you want there to be individual allocators (of the same type) that you want to point differently based on <X condition>. For example in a M:N greenthreaded system perhaps you want each greenthread to have its own arena allocator. But you can't use something like threadlocal, because at any time a greenthread might move to any given OS thread? Is that possible in rust?

[steveklabnik → throwawaymaths]

1. You can do anything you want in Rust, you can make your own collections do whatever you want at any time.

2. These changes are about two things,

2a. the first of which is a trait that represents the concept of an allocator, in case users' code would like to be generic over ones that exist in the ecosystem. You can of course still paper over this yourself but the whole point of a vocabulary trait is so that you don't have to do all the work yourself.

2b. the second of which is how the collections in the standard library are customized by allocators.

So, in your own code, absolutely you could do that if you wanted to. With this proposal, and trying to do that with a standard library provided data structure? I'm not an expert on the API that it gives, so I can't really speak to its viability here. I would imagine it's not super simple, given what I do know.

[throwawaymaths → steveklabnik]

sorry, I should have been clear: I meant with a standard lib provided data structure.

Thanks!

[monocasa → throwawaymaths]

Yes, the data structures in std are parameterized over the allocator, with Global as the default allocator if not specified.

https://doc.rust-lang.org/std/vec/struct.Vec.html

[throwawaymaths → monocasa]

The point is, they are parametrized over a type, not an instance. By contrast, types in zig that are variadic by allocator are (typically) parametrized over instance.