Rust heads into the kernel?

One point thusfar unmade is that the Linux Kernel Style is outdated whether compared to Rust or not. This is to be expected of a thirty year old code base started when ANSI C was still a tad moist behind the ears. Since then there have been two significant standard revisions, both introducing various syntax and library updates of which the kernel style has been slow to adopt the former and generally ignores the latter[0].

It's not reasonable to expect a hojillion-SLOC program to undergo style churn to any degree, and matters like whether switch-cases should be indented or not shall remain a matter of taste forevermore. However, the kernel style (henceforth LKS) has several issues that, mostly consequent to influence of other languages, appear silly today: for example, LKS bars oneliners of the form "if((asdf, sdfg < 666) || (qwer && hjkl)) return PTR_ERR(EWOULDHORK);", instead preferring not even the Perl convention of extra curlies, but placing the return after the if and indenting it one level. Whether this is related to early-onset ergonomy trouble of the right thumb is anyone's guess.

Another example is LKS' propensity for spending vertical space willy-nilly instead of as a means to visually separate subprograms into a tripartite acquire-operate-release[1] form (or for telling apart subsections thereof), perhaps dating back from when text consoles had one or two fonts and no options for vertical spacing so programmers would compensate by adding spaces and linebreaks to improve superficial comprehensibility[2].

Moreover some syntax updates introduced in C99 have gone by the wayside; even today there's code being submitted that introduces variables at start-of-block when inline has been common preference for some 2/3rds of Linux being around, and (to my knowledge anyway) GCC 2.95 hasn't been a supported compiler for a dog's age. You'd also be hard pressed to find any use of struct literals or ephemeral dummies even as they improve both security and legibility by leaving no fields uninitialized as struct/union definitions grow and disallowing typo-based coding mistakes (i.e. the ones that bleary-eyed review misses) when the same pointer is dereferenced a bunch of times in sequence.

So whether Rust[3] is adopted or not, I for one hope the experiment at least leads to some revision in the Linux Kernel Style.

As for language extensions, that way lies the day when someone suggests adding an introspectable type system and deprecating implicit downcasts from void-pointers (we've all been down there, I hope) so that "C<>" can have Safe Iterators; and at that point you might as well follow the Ada rabbithole and start writing formal design proposals and other top-down necktie junk. That one proposal about scoped mutex unlocks is already incredibly horrible simply because tying mutex unlocks to scope exit is the smell of a function with another, smaller function in it, waiting to burst forth all over your breakfast spaghetti.

(Also, the LKS block comment style sucks basketballs wrapped in barbed wire through a garden hose, then pleads for seconds in the ECHR. You'd have to be coming off Borland's Turbo Space Crack to think it's a good idea even in 1992.)

[0] i.e. <stdint.h> types are ignored in favour of u8, u16, etc.; <threads.h> and <stdatomic.h> are right out; and who's even heard about <stdnoreturn.h>?
[1] read-compute-write, plan-setup-test-cleanup, disable-access-enable, etc.
[2] which is quite important for recognizing patterns at a glance, and telling whether something unusual is going on that ought to have a closer look right away
[3] or a future xon-of-Rust, or Ada, or ATS, or whatever floats your boaty mcboatface