It's backwards incompatible to change because unsafe code assumes it. But when we have a hierarchy of Sized traits, we can add a rung for this (below Sized so not the default) and new code could support these types.
For rustc, open a PR and nominate for lang.
The most natural order would be if it were upgraded in clippy first. It isn't strictly necessary but gives confidence in the impl. If you face resistance to that, lang could weigh in and say we want this, assuming the rest of the team agrees with me.
This should be upgraded to warn by default and promoted to rustc imo. Is it ever correct to want the other thing?
(Still MaybeIncorrect fix because it can break existing code I guess)
Yes, that's reasonable to assume because deref coercions literally let you do that. It's just that the impl Any for Box<dyn Any> causes unsizing coercion to take precedence.
We should look into changing this behavior in future editions.
the mobile client does. it only shows messages from one instance at a time.
New features in glidewm.org since I announced it here. Thanks to our new contributors!
• Mission Control integration
• Resize windows with your keyboard
• glide launch --restore
• Status bar icon
• Install with homebrew (brew install glide)
+ bug fixes and other improvements
Feel free to open an issue if it's a problem for you in Glide
Yeah I mean, I said basically that in a nice way asking if we could work together and was ignored github.com/acsandmann/r...
intro splash screen for interview of Taylor Cramer, Crubit Development Lead at Google
new interview with Taylor Cramer, development lead of Crubit
wanna hear about C++/Rust interop? wanna peek inside the mind of a language nerd?
another one from the Rust Project Content Team
I wish I knew! The maintainer forked the codebase without talking to me, committed all the code under their name, and then announced it on HN.
Yep that's literally the idea! :)
Amethyst does it already. But you have to handle some windows specially that don't have title bars, add delays between events, etc
Yeah I have an open issue on how to implement it without SIP but it's not trivial
Yeah I would definitely accept contributions on the second, feel free to open an issue and we can discuss. I'm not sure what is meant by stacked windows, it sounds like a feature Glide has (I think briefly shown in the video) but maybe slightly different.
It uses n-ary trees like sway/i3 instead of bsp so you can have e.g. 3 column layouts. No functionality depends on disabling SIP. Newer project so less functionality overall.
Not under development but I am curious about how Glide could support it; it looks useful. You might want to check out github.com/karinushka/p...
The biggest difference is support for native spaces
Announcing Glide, a tiling window manager I've been working on for macOS.
glidewm.org
ai generated code seems akin to plastic: revolutionary, cheap, moldable, and in a few years we will be desperately looking for ways to reduce reuse recycle
I agree, the version I like actually has awaits, even in async-agnostic code. So you model the effects explicitly even when they might not happen.
I'm referring to a call graph like
async fn -> higher order generic code -> async fn or closure
The code in the middle is e.g. standard library code like iterator combinators that you want to be generic over async and have the same behavior in both. But sometimes you want to specialize
I'm personally open to this idea but not yet convinced one way or another.
This leads to two interesting ideas.. effect generics and effect specialization. Sometimes you want code "in the middle" to be the same, but not when you branch back out.
Async is a generalization; this means you can express more patterns in async than you can in sync.
However, some generic code would be written the same in both.
hate it when programs present you with a text input and it's NOT READY FOR YOU TO TYPE IN — like wdym?? I'm a meatbag full of water! You're a monster running at 4.5 GHz!!! How am I waiting on you!
`T: Copy` is therefore a stronger bound than `T: !Drop` that tells you neither the type nor its fields (transitively) implement Drop.
Side note, Drop is a weird trait that technically means "defines its own drop glue in addition to whatever its fields do", there is nothing transitive about whether a type implements Drop.
!Trait bound means the type promises to /never/ implement Drop, which usually requires an explicit negative impl (also unstable). In the case of Drop, `T: Copy` is a good approximation.
Screenshot of a list of three header files in a github repo. One of the files, updated last year, shows a commit message of "memory safety or whatever".
heh
me: well, there's this cave with a bunch of spiders
This is Not Okay and this is very cool
