> Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result)

?!!??u32 is a perfectly cromulent type in Zig.

How do you express the difference between None and Some(None) in Zig?

I've found that types like these normally come up in generic contexts, so the code I'm writing only usually deals with one layer of Option or Result until I get to the bit where I'm actually using the value and find out I have to write "try try foo();". That said, I think this sort of thing will do it:

  const std = @import("std");
  fn some(x: anytype) ?@TypeOf(x) {
    return x;
  }
  fn print_my_guy(maybe_maybe_x: ??u32) void {
    if(maybe_maybe_x) |maybe_x| {
      if (maybe_x) |x| {
        std.debug.print("that's Some(Some({d})) {any}\n", .{x, maybe_maybe_x});
      } else {
        std.debug.print("that's Some(None) {any}\n", .{maybe_maybe_x});
      }
    } else {
      std.debug.print("that's None {any}\n", .{maybe_maybe_x});
    }
  }
  pub fn main() void {
    const a: ??u32 = 5;
    const b: ??u32 = null;
    const c: ??u32 = some(@as(?u32, null));
    print_my_guy(a);
    print_my_guy(b);
    print_my_guy(c);
  }

What about

  const std = @import("std") ;
  const print = std.debug.print ;
  
  pub fn main() void {
  
    const simple_none : ?u8 = null ;
  
    const double_optional_none : ??u8 = null ;
  
    const double_optional_some_none : ??u8 = simple_none ;

    print("none equals some none: {}", .{ double_optional_none == double_optional_some_none });
    // prints none equals some none: false
  
  }

> Rust's const-eval is very constrained and has been WIP for ages

Having strong backwards compatibility does that to the language, alternative is arguably worse (see Python 2 vs 3).

Yes, and I don't want a backward-incompatible Rust 2.0 either, but the slowness of stabilizing ! (named for when it's going to be stabilized), specialization, TAIT, const-eval, Vec::drain_filter, *Map::raw_entry, ... is annoying. Also the lack of TAIT currently causes actual inefficiency when it comes to async traits, because currently async trait methods have to return allocated virtualized futures instead of concrete types. Same for Map::raw_entry, without which you have to either do two lookups (`.get()` + `.entry()`) or always create an owned key even if the entry already exists (`.entry(key.to_owned())`).

If you think, that's bad, look at C/C++ standardization bodies, where stuff is eternally blocked because ABI compatibility.

---

Problem is lots of implementation things are vying for inclusion. And many thing people want aren't safe or block/are blocked by possible future changes.

For example default/named arguments were blocked by ambiguity in parsing when it comes to type ascription iirc. And not having default arguments makes adding allocator quite more cumbersome.

Plus Rust maintainers are seeing some common patterns and are trying to abstract over them - like keyword generics/ effect system. If they don't hit right abstraction now, things will be much more harder later. If they over abstract, its extremly hard to remove it.

---

Slowness of stabilizing never type (!) and specializations has to do with the issues they cause mainly unsoundness and orphan rules issues, iirc I haven't checked them in a while.

But otherwise yeah, Unstable book keeps growing and growing: https://doc.rust-lang.org/unstable-book/index.html