<re_irc>
<@adamgreig:matrix.org> ....but, using apostrophes
<re_irc>
<@adamgreig:matrix.org> And a sort of C version of checked_add and checked_sub, and finally something rust doesn't already have in arbitrary width integers
<re_irc>
<@dirbaio:matrix.org> arbitrary-width ints in rust would be awesome...
<re_irc>
<@dirbaio:matrix.org> plus something like `#[repr(bitfield)]`..
<re_irc>
<@adamgreig:matrix.org> Yea...
<re_irc>
<@dirbaio:matrix.org> no more svd2rust :D
<re_irc>
<@dirbaio:matrix.org> (jk)
<re_irc>
<@firefrommoonlight:matrix.org> So, embedded engineers will start taking advantage of that in a few decades?
<re_irc>
<@dirbaio:matrix.org> I guess? when their proprietary compilers get updated
<re_irc>
<@dirbaio:matrix.org> by then they'll have moved to rust
<re_irc>
<@adamgreig:matrix.org> I guess with these new features C will finally be suitable for embedded dev :p
<re_irc>
<@adamgreig:matrix.org> The syntax is kinda upsetting
<re_irc>
<@adamgreig:matrix.org> _BitInt(24) x = 0b1111'0000;
<re_irc>
<@therealprof:matrix.org> adamgreig: Told ya so.
<re_irc>
<@richarddodd:matrix.org> I personally think that changing `async` from meaning "this function lies about its return type: instead of `T` it returns a `Future<Output=T> + '_`", to "just syntatic sugar for an async block inside the function body" seems sensible.
<re_irc>
<@thalesfragoso:matrix.org> richarddodd:matrix.org: I end up writing a lot of `fn() -> impl Future` due to some limitations of async fn, so maybe
<re_irc>
<@thalesfragoso:matrix.org> It kinda makes sense for traits
<re_irc>
<@dirbaio:matrix.org> O-o
<re_irc>
<@dirbaio:matrix.org> what would `async fn blah() -> u32` do then?
<re_irc>
<@dirbaio:matrix.org> compile error?
<re_irc>
<@richarddodd:matrix.org> The motivating case they talk about is `impl Future<..> + Send`.
<re_irc>
<@richarddodd:matrix.org> you could return `impl Future` or you could return a concrete type that implements future (and maybe some other stuff)
<re_irc>
<@thalesfragoso:matrix.org> Maybe both have its use though
<re_irc>
<@thalesfragoso:matrix.org> In traits having `-> GATType` makes a lot of sense
<re_irc>
<@thalesfragoso:matrix.org> Where GATType impl Future
<re_irc>
<@dirbaio:matrix.org> yeah but then why have the `async`?
<re_irc>
<@dirbaio:matrix.org> ```rust
<re_irc>
<@dirbaio:matrix.org> type FooFut<'a> = impl Future<Output = usize>;
<re_irc>
<@richarddodd:matrix.org> Full disclosure: my views are motivated by wanting to keep the Rust language as small as possible, and I get tremendous pleasure when someone finds a way to remove features without losing functionality or ergonomics
<re_irc>
<@dirbaio:matrix.org> that's exactly the same with `async` and without
<re_irc>
<@richarddodd:matrix.org> dirbaio:matrix.org: As shorthand for `fn foo() -> impl Future { async move { .. } }`
<re_irc>
<@thalesfragoso:matrix.org> Hmm, I would expect the async not to be there
<re_irc>
<@dirbaio:matrix.org> so it seems this is simply calling for "don't do async traits, just stick with GATs"
<re_irc>
<@dirbaio:matrix.org> ah duh ignore me
<re_irc>
<@richarddodd:matrix.org> So the feature is reduced to a single thing: async blocks.
<re_irc>
<@dirbaio:matrix.org> the trait *definition* indeed doesn't say `async`
<re_irc>
<@richarddodd:matrix.org> (I'm actually not that bothered what is decided I'm still happy/this is bikeshedding)
<re_irc>
<@richarddodd:matrix.org> but it's interesting to talk about
<re_irc>
<@thalesfragoso:matrix.org> I think once GAT is stable, people will get very used to not use async fn sintaxe sugar
<re_irc>
<@dirbaio:matrix.org> it somewhat bothers me that "async fn" is now no longer "important for the caller"
<re_irc>
<@dirbaio:matrix.org> like
<re_irc>
<@dirbaio:matrix.org> the caller doesn't care at all whether it's `fn foo() -> impl Future<Output=u32>` or `async fn foo() -> impl Future<Output=u32>`
<re_irc>
<@dirbaio:matrix.org> so presumably it shouldn't even show up in rustdoc
<re_irc>
<@dirbaio:matrix.org> same way as `fn foo(mut x: u32)` vs `fn foo(x: u32)` doesn't show up
<re_irc>
<@richarddodd:matrix.org> yeah I've thought before that it would be handy if rustdoc would convert `fn foo() -> impl Future<Output=T>` to `async fn foo() -> T`
<re_irc>
<@dirbaio:matrix.org> uh then how would rustdoc show the Send bounds :D :D
<re_irc>
<@metreo:matrix.org> apparently the direction is that it's supposed to feel native either way to the user
<re_irc>
<@richarddodd:matrix.org> (but this is another reason I'm not super keen on async functions: they create an equivalence class: there multiple ways to write the same function signature)
<re_irc>
<@metreo:matrix.org> apparently it won't matter from the users pov
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> it's just Too Much Magic
<re_irc>
<@dirbaio:matrix.org> the reality is you simply can't abstract futures away
<re_irc>
<@metreo:matrix.org> that's the direction aifak correct me if I'm misunderstanding the dialog around it
<re_irc>
<@dirbaio:matrix.org> it depends
<re_irc>
<@dirbaio:matrix.org> I've seen some folks on rust zulip to push hard for MORE syntax sugar and MORE magic
<re_irc>
<@adamgreig:matrix.org> what happened with that earlier discussion about async with people who wanted it to be Even Easier and it got mixed up in DMA safety?
<re_irc>
<@dirbaio:matrix.org> not much...
<re_irc>
<@dirbaio:matrix.org> only way to really fix that is to add the "Leak" auto trait
<re_irc>
<@dirbaio:matrix.org> which is Quite Unpopular
<re_irc>
<@adamgreig:matrix.org> alas...
<re_irc>
<@metreo:matrix.org> if not impossible*
<re_irc>
<@richarddodd:matrix.org> I would vote for it..
<re_irc>
<@dirbaio:matrix.org> everything else is uacks
<re_irc>
<@richarddodd:matrix.org> Or you have to have the caveat that "this method can be unsafe even in safe rust if you leak the future"
<re_irc>
<@dirbaio:matrix.org> the "run to completion futures" proposal workarounds it by just making `poll()` unsafe requiring "hey, pretty please, poll this to completion thanks"
<re_irc>
<@metreo:matrix.org> again afiak safe leaking is impossible to implement
<re_irc>
<@dirbaio:matrix.org> and it's only useful for futures
<re_irc>
<@richarddodd:matrix.org> metreo:matrix.org: I vaguely remember this being 'undecidable' or some other computer science thingy
<re_irc>
<@dirbaio:matrix.org> you often want to make something unleakable that's *not* a future
<re_irc>
<@dirbaio:matrix.org> it's easy to guarantee at compile time that something is not leaked
<re_irc>
<@richarddodd:matrix.org> dirbaio:matrix.org: I'm pretty sure you could screw up on linux using flie descriptors and mmap in safe rust via. leaking
<re_irc>
<@dirbaio:matrix.org> just don't allow putting it in stuff that may leak it such as mem::forget, Box::leak, Arc, etc
<re_irc>
<@dirbaio:matrix.org> the most "painful" one is Arc
<re_irc>
<@thalesfragoso:matrix.org> metreo:matrix.org: You can with Rc cycles
<re_irc>
<@metreo:matrix.org> one issue was safe leaking, so there was no way to conveniently ensure the leak didn't expose sensitive data
<re_irc>
<@metreo:matrix.org> like the whole stack leaks or nothing at all or something
<re_irc>
<@richarddodd:matrix.org> ```rust
<re_irc>
<@richarddodd:matrix.org> let mut b = Rc::new(a.clone());
<re_irc>
<@richarddodd:matrix.org> let mut a = Rc::new(RefCell::new(None));
<re_irc>
<@richarddodd:matrix.org> Tbf GhostCell is a good solution for this problem
<re_irc>
<@richarddodd:matrix.org> Not sure if that's what the emoji meant :P
<re_irc>
<@adamgreig:matrix.org> the argument was to add an auto trait for things that may be leaked which Rc and etc would require, so all the ways to create safe leaks would require the type be Leak
<re_irc>
<@adamgreig:matrix.org> but it allows some things to not be allowed to be leaked
<re_irc>
<@adamgreig:matrix.org> (and they can't then be used inside those leaky constructs)
<re_irc>
<@richarddodd:matrix.org> Is there any way to leak memory using rust without `std`? I think not because you can't even access the heap.
<re_irc>
<@metreo:matrix.org> eeh it looks like RFC 2984 has been pulled that would have been `T: ?Leak`
<re_irc>
<@richarddodd:matrix.org> Which means that the `Leak` strategy should work? I think.
<re_irc>
<@thalesfragoso:matrix.org> Maybe one push back is that we kinda have a type that prevents leaking, Pin with !Unpin data
<re_irc>
<@adamgreig:matrix.org> aiui the objection was not that it couldn't be done, but reluctance to add a new auto trait
<re_irc>
<@thalesfragoso:matrix.org> But it's a pain and doesn't work for borrows
<re_irc>
<@richarddodd:matrix.org> I know that the core Rust people are really interested in embedded, and I think if someone wrote up a doc that said "embedded is great - look how easy it is to write code that runs better than C, but to make it safe we must have X (e.g. Leak trait)" that would be compelling for them.
<re_irc>
<@dirbaio:matrix.org> Pin says "drop MUST run before the memory for self is reused for something else"
<re_irc>
<@dirbaio:matrix.org> !Leak would require "drop MUST run before Self's lifetime ends"
<re_irc>
<@dirbaio:matrix.org> !Leak is stronger
<re_irc>
<@dirbaio:matrix.org> you can still leak shit inside a Pin
<re_irc>
<@metreo:matrix.org> but you can't prove that the leak did or didn't happen
<re_irc>
<@thalesfragoso:matrix.org> It has some guarantees but far from !Leak
<re_irc>
<@metreo:matrix.org> afiak pinning is either leak it and preserve the guard or drop the guard
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: Yeah, that's why the doesn't work for borrows part :/
<re_irc>
<@dirbaio:matrix.org> metreo:matrix.org: metreo: the TLDR of the proposal is:
<re_irc>
<@dirbaio:matrix.org> - Add a new auto trait Leak.
<re_irc>
<@dirbaio:matrix.org> - Add a new "safety requirement": If a type T is !Leak, for each instance of T its drop MUST run before T's lifetime ends"
<re_irc>
<@dirbaio:matrix.org> - Change all structs/functions that leak things to require "T: Leak". This includes mem::forget, MaybeUninit, ManuallyDrop, Box::leak, Rc, Arc...
<re_irc>
<@dirbaio:matrix.org> with these changes you absolutely can guarantee that not-Leak stuff is not leaked at compile time
<re_irc>
<@dirbaio:matrix.org> the goal is not "prove at compile time that a program has no memory leaks at all"
<re_irc>
<@dirbaio:matrix.org> it is "give library authors a tool to do unsafe operations that need a "must not leak guarantee" to be sound"
<re_irc>
<@dirbaio:matrix.org> for example to do DMA operations
<re_irc>
<@dirbaio:matrix.org> normal memory leaks are not UB
<re_irc>
<@dirbaio:matrix.org> but leaking a DMA future would be UB
<re_irc>
<@richarddodd:matrix.org> Yeah I think this is a way to see it: "give hardware library authors richer tools to express the safety requirements of their API"
<re_irc>
<@dirbaio:matrix.org> add a language feature so the API can be safe, instead of unsafe with a "plz no leak" safety requirement :)
<re_irc>
<@dirbaio:matrix.org> pleasies no leakies
<re_irc>
<@dirbaio:matrix.org> I wonder what's the usability impact of not being able to put things inside Arc's
<re_irc>
<@richarddodd:matrix.org> Part of the reason I don't mind it is that it is *not* a language feature - it's just a type in `core`, with some auto impl
<re_irc>
<@richarddodd:matrix.org> dirbaio:matrix.org: In `no_std`, not much...
<re_irc>
<@dirbaio:matrix.org> for embedded not much yeap
<re_irc>
<@dirbaio:matrix.org> but the "no leak" thing would be used in other contexts too
<re_irc>
<@dirbaio:matrix.org> for example it's been a problem for io-uring bindings too
<re_irc>
<@dirbaio:matrix.org> (io-uring is essentially "DMA done by the kernel to process memory")
<re_irc>
<@dirbaio:matrix.org> and std-ful async people LOVE their Arcs
<re_irc>
<@dirbaio:matrix.org> presumably it'd be only the futures that are !Leak
<re_irc>
<@dirbaio:matrix.org> not the File/Socket structs
<re_irc>
<@dirbaio:matrix.org> so maybe not too bad..?
<re_irc>
<@dirbaio:matrix.org> you never stick futures in Arcs
<re_irc>
<@richarddodd:matrix.org> The docs for the `Leak` trait would look something like
<re_irc>
<@richarddodd:matrix.org> > This trait indicates that the type can be safely leaked. This is almost always the case - you only need to concern yourself with `!Leak` types when working with low-level APIs.
<re_irc>
<@richarddodd:matrix.org> dirbaio:matrix.org: This is another place where I think `Leak` could be really useful.
<re_irc>
<@dirbaio:matrix.org> Executors stick futures in Arcs, heh
<re_irc>
<@dirbaio:matrix.org> or kinda,
<re_irc>
<@dirbaio:matrix.org> they do arc-like refcounting manually
<re_irc>
<@firefrommoonlight:matrix.org> richarddodd:matrix.org: I think the key will be demonstrating Rust in embedded in a variety of commercial or otherwise popular projects
<re_irc>
<@firefrommoonlight:matrix.org> With a target not so much as people who already like Rust, but people who make embedded devices
<re_irc>
<@richarddodd:matrix.org> firefrommoonlight:matrix.org: I'm *sure* this will happen. E.g. https://www.oxionics.com/
<re_irc>
<@firefrommoonlight:matrix.org> And that's cool
<re_irc>
<@richarddodd:matrix.org> I mean, yeah startup yada yada but the way you can write proper zero-cost rich high-level safe APIs is soooooooooo compelling
<re_irc>
<@firefrommoonlight:matrix.org> Ie, right now a lot of the Rust embedded OSS stuff is geared towards makers etc, and targetting people who want to solve a problem in Rust, vice wanting to solve a problem, and choosing Rust
<re_irc>
<@firefrommoonlight:matrix.org> I think that link is fantastic - we just need more of it!
<re_irc>
<@dirbaio:matrix.org> *creating* problems just to solve them in Rust 👌
<re_irc>
<@metreo:matrix.org> creating Rust then solving Rust problems
<re_irc>
<@firefrommoonlight:matrix.org> That attitude is so prevalent in the Python community, that we have MicroPython
<re_irc>
<@firefrommoonlight:matrix.org> !!
<re_irc>
<@dirbaio:matrix.org> micropython lool
<re_irc>
<@firefrommoonlight:matrix.org> I love Python in its lane, but holy shit guys
<re_irc>
<@metreo:matrix.org> firefrommoonlight:matrix.org: go on...
<re_irc>
<@richarddodd:matrix.org> I mean I love python, but the offering here is that you don't lose anyting by moving over to Rust (obv that isn't quite true yet, but we're working on it!)
<re_irc>
<@dirbaio:matrix.org> it's used mostly by hobbyists though
<re_irc>
<@firefrommoonlight:matrix.org> I could easily see [Rust] moving away from that, but not python-on-embedded
<re_irc>
<@dirbaio:matrix.org> if you're not manufacturing anything in volume, you don't care if your firmware uses 10x the flash/ram it could
<re_irc>
<@richarddodd:matrix.org> Rust, with drivers, is *easy* enough to use for hobbyists, but *powerful* enough for professional application
<re_irc>
<@dirbaio:matrix.org> you're paying the giant adafruit/sparkfun/arduino markups anyway :D
<re_irc>
<@richarddodd:matrix.org> I, a hobbyist, can confirm that it's really expensive.
<re_irc>
<@dirbaio:matrix.org> and if you run out of flash/ram you just grab a full fat raspi
<re_irc>
<@dirbaio:matrix.org> with 4gb ram, 32gb sdcard, and a freaking desktop environment
<re_irc>
<@richarddodd:matrix.org> therealprof:matrix.org: Love that guy
<re_irc>
<@dirbaio:matrix.org> so you get to run your nodejs webserver
<re_irc>
<@dirbaio:matrix.org> using 10000x the RAM, no probs 👌
<re_irc>
<@richarddodd:matrix.org> My motivation is slightly different from shipping real stuff: I like the aesthetic side of using minimum resources.
<re_irc>
<@firefrommoonlight:matrix.org> I do to. Or, more specifically, I like how you can make programs that get a job done, with no noticeable latency