What are we expecting in 0.17?

the secret sauce is that andrew often sorts PRs by recently updated. don’t be annoying about it, but i’d bet that a week with no activity = the PR falls off the first page of that list, so I’d feel free to bump it up with a comment. one of my recent PRs needed two such bumps.

This also has the benefit of keeping community spaces more friendly for hanging out. Kinda like how you don’t usually wanna be hanging out at the bar with somebody and tell them “hey, you owe me a reply to my email” right in the best part of the hang.

4 Likes

Yeah, that’s really the first time I actively ping him about it.

Awesome, proud of you! Do it on Codeberg and it’ll be even more effective :slight_smile:

Yes, that’s not a good approach for the reasons you state. I’m definitely not suggesting removing the vtable, as that’s the core of the (quite excellent) abstraction. Instead you’d want a type erased version of every Reader/Writer function using anyerror (take*, peek*, write*, etc). These functions become the single version of the machine code (with all the cache benefits). Then in the monomorphized returned struct you’ve just got a bunch of (inline?) wrappers around the type erased functions that cast from anyerror to the specific error set. Then each specialized type isn’t actually generating any machine code.

This isn’t quite enough on its own, you’d need a bit more metaprogramming to create a cast function to take a Reader/Writer type instance from one error set to a superset of that error set. This is all comptime type manipulation, not actual runtime machine code. You’d need this cast function for your example of passing Writers with different error sets into a single handling function that takes the union of both Writer’s error sets. It’d be great to have language features to automate/hide this cast, but I don’t think it’s actually necessary for functionality.

You could use anyerror in the functions for implementing the vtable, or metaprogramming to do the functions casts with proper checking. I don’t have strong feelings on this aspect, since people are rarely implementing Readers/Writers.

Personnally I’m exited that 0.17 crosses the usability threshold for incremental build of my project.

The meta programming SoA rewrite is gonna be a bit painful, but also simplify common patterns and hopefully also speed up that part of compilation.

For std.Io it’s ok in the current form for simple tasks, but there are good arguments for adding error.Canceled in this thread Making it harder to swallow `error.Canceled` - #60 by lalinsky pointing to several bugs in std showing current solution is pointy on both sides

3 Likes