pattern_typesThis RFC introduces pattern types, which are subtypes of matchable types that
are statically restricted to a subset of the variants of the original type.
W3C teams have a tendency of scribing everytihng they do, and they're pretty effective at it.
This is not due to individuals being great at scribing: the system is set up such that even new group members will be able to scribe reasonably effectively. It's also set up such that new group members will get that opportunity soon enough.
The main thing is that "anyone can scribe": most teams avoid a designated scribe and instead designate a scribe per meeting and discussion. This works with some of the following additional structure:
How to use:
./wordle.sh
Or try the unlimit mode:
September 2022:
This has spread to a far wider audience than I had anticipated - probably my fault for using a title that is in hindsight catnip for link aggregators. I wrote this back in 2021 just as a bunch of personal thoughts of my experiences using Rust over the years (not always well thought through), and don't intend on trying to push them further, outside of personal experiments and projects.
Managing a living language is challenging and difficult work, and I am grateful for all the hard work that the Rust community and contributors put in given the difficult constraints they work within. Many of the things I listed below are not new, and there's been plenty of difficult discussions about many of them over the years, and some are being worked on or postponed, or rejected for various good reasons. For more thoughts, please see my comment below.
This is an analysis of how variadic generics could be added to Rust. It's not a proposal so much as a summary of existing work, and a toolbox for creating an eventual proposal.
Variadic generics (aka variadic templates, or variadic tuples), are an often-requested feature that would enable traits, functions and data structures to be generic over a variable number of types.
To give a quick example, a Rust function with variadic generics might look like this:
The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the
| # source:http://geocities.com/SiliconValley/heights/7052/opcode.txt | |
| From: mark@omnifest.uwm.edu (Mark Hopkins) | |
| Newsgroups: alt.lang.asm | |
| Subject: A Summary of the 80486 Opcodes and Instructions | |
| (1) The 80x86 is an Octal Machine | |
| This is a follow-up and revision of an article posted in alt.lang.asm on | |
| 7-5-92 concerning the 80x86 instruction encoding. | |
| The only proper way to understand 80x86 coding is to realize that ALL 80x86 |
I recently happened upon a very interesting implementation of popen() (different API, same idea) called popen-noshell using clone(2), and so I opened an issue requesting use of vfork(2) or posix_spawn() for portability. It turns out that on Linux there's an important advantage to using clone(2). I think I should capture the things I wrote there in a better place. A gist, a blog, whatever.
This is not a paper. I assume reader familiarity with
fork()in particular and Unix in general, though, of course, I link to relevant wiki pages, so if the unfamiliar reader is willing to go down the rabbit hole, they should be able to come ou