The feedback form was open for some amount of time and closed as scheduled, there are only so many things to be said about the draft after all. All of the things mentioned in the blog post have been said hundreds of times over by this point
Where are you getting that they might accept the draft from? That seems like a particularly uncharitable reading of the follow up post
TrustedLen will mean it can safely take the upper bound, but Vec for example will still use the lower bound of the hint when something isn't TrustedLen
Ooh nice, I hadn't seen that. OK, so there are probably places where I assumed the iterator won't do as nice a job of collect() as I did manually but I was wrong.
I wonder how the hell I didn't see that when I was tracking down how collect() ends up caring about TrustedLen.
The idea is you read the PKGBUILD/install files so it's no longer arbitrary code, they're usually very short files. On updates you can review just a diff. AUR helpers present this to you so it's not a manual process
Many packages are compiled from source rather than using prebuilt binaries, but when binaries are fetched it is something you'd see in the PKGBUILD itself. The binaries aren't included in the AUR itself, they'd usually be from the first-party of the software you're installing. For example google-chrome[1]'s package fetches the .deb from Google's server and unpacks it
None of these scriptlets would break if a site uses WASM, they're utilities for things like adding/removing/mutating elements from the DOM, modifying localStorage, stopping alert()
executesitefunction.js could arguably be effected, but that relies on a site installing a particular function on window, which isn't required when using JS, and could be still done where the function is backed by WASM
uft8mb4 does not use more bytes than utf8mb3, for anything representable by utf8mb3 the size in uft8mb4 is identical. Anything that would be 4 bytes in uft8mb4 is not able to be stored in utf8mb3
utf8mb3 is definitely a broken subset, it's deprecated at the very least
One can use the Freetype library to render beautifully sharp text directly to a canvas with gamma-correct subpixel alpha coverage. Why this Rust website uses such blurry fonts, I don't know, it reminds me of playing an OpenGL/DirectX video game where the text is rendered using cached texture-filtered quads: maybe good enough for game UI, but not for intensive reading.
For those wondering why: subpixel rendering requires knowing the subpixel layout of the display. It’s something your OS knows, but your web browser doesn’t tell the website.
Also for those wondering how you can get subpixel AA on your canvases anyway: if you use a classic 2d rendering context (not WebGL), you can use canvas.getContext("2d", {alpha: false}) to create a canvas with a fully opaque background, which will also cause fillText to render with subpixel AA on most browsers.
Jumping to definition works with typescript projects correctly when this is turned on, but it's still not a solution for JS projects with definition files
Where are you getting that they might accept the draft from? That seems like a particularly uncharitable reading of the follow up post
https://foundation.rust-lang.org/news/rust-trademark-policy-...