In Rust, you provide a string — that is injected to be invoked internally. In C++, we’d just provide a callable.
This is because Rust’s attribute grammar can’t support a callable here.
I don’t do C++ as a life choice, and thus not 100% sure what the author means here. But I have the feeling that he is wrong, on multiple levels even 😉
Last week I basically duplicated the serialization code to provide better debug output…
Why was duplication needed, instead of implementing Debug using serialized output?
And why would one want to rename stuff…etc in Debug
anyway? It’s for debugging?
This looks like purpose mismatch to me.
Also:
A short post on how variable names can leak out of macros
I don’t think you understood the blog OP!
Maybe a good idea for a post. But the amount of reaches required makes this icky.
let Ok(x) = read_input() else { return Err(Error) };
instead of let x = read_input().map_err(|_| ...)?;
const x: &str = "...";
instead of const X: &str = "...";
Maybe there is a reason after all why almost no one (maybe no one, period) was ever in that situation.
you’re not supposed to immediately reach for macros
correct
for small things you don’t quite like about the language.
incorrect
Excessive macro use makes it impossible for others (including your future self) to read your code
N/A. the macro above is trivial.
impossible for others to read your code and there’s often good reasons why it’s designed like it is.
fiction
There is a general mechanism in Rust that allows language users to add their own sugar. It’s called macros 😉
macro_rules! keep {
(let $id:ident = $expr:expr => $($tt:tt)+) => {
let $id = $expr;
let $id = $id$($tt)+;
}
}
fn main() {
keep!{ let path = std::env::current_dir().unwrap() => .as_path() };
println!("{path:?}");
}
You can remove let
from the macro’s fragment specifier and invocation.
mastering_rust
Maybe wait until you’re actually good at it.
Rebinding with and without mut
is a known and encouraged pattern in rust. Leaving things as mut
longer than necessary is not.
Bringing vimperator/pentadactyl back! That would be the dream.
Anyway, last time I tested it (~3 weeks ago), servo
was not very usable still with the few websites I tried. Hopefully it gets, at least partway, there in a few months.
Neither.
new()
give you a fully valid and usable struct value.Maybe you should also use substructs that hold some of the info.
a better solution would be to add a method called something like ulock that does a combined lock and unwrap.
That’s exactly what’s done above using an extension trait! You can mutex_val.ulock()
with it!
Now that I think about it, I don’t like how unwrap can signal either “I know this can’t fail”, “the possible error states are too rare to care about” or “I can’t be bothered with real error handing right now”.
That’s why you’re told (clippy does that i think) to use expect
instead, so you can signal “whatever string” you want to signal precisely.
if you’re really that bothered…
use std::sync::{Mutex, MutexGuard};
trait ULock<'a> {
type Guard;
fn ulock(&'a self) -> Self::Guard;
}
impl<'a, T: 'a> ULock<'a> for Mutex<T> {
type Guard = MutexGuard<'a, T>;
fn ulock(&'a self) -> Self::Guard {
self.lock().unwrap()
}
}
or use a wrapper struct, if you really really want the method to be called exactly lock
.
If lock-ergonomicsⓒ is as relevant to you as indexing, you’re doing it wrong.
I would rather take indexing returning Result
s than the other way around.
One can always wrap any code in {||{ //.. }}()
and use question marks liberally anyway (I call them stable try blocks 😉).
…and that’s how you drive up metrics.
Gross!
Unprofessional.
This is why no one takes Rust seriously.
but futures only execute when polled.
The most interesting part here is the polling only has to take place on the scope itself. That was actually what I wanted to check, but got distracted because all spawns are awaited in the scope in moro
’s README example.
async fn slp() {
tokio::time::sleep(std::time::Duration::from_millis(1)).await
}
async fn _main() {
let result_fut = moro::async_scope!(|scope| {
dbg!("d1");
scope.spawn(async {
dbg!("f1a");
slp().await;
slp().await;
slp().await;
dbg!("f1b");
});
dbg!("d2"); // 11
scope.spawn(async {
dbg!("f2a");
slp().await;
slp().await;
dbg!("f2b");
});
dbg!("d3"); // 14
scope.spawn(async {
dbg!("f3a");
slp().await;
dbg!("f3b");
});
dbg!("d4");
async { dbg!("b1"); } // never executes
});
slp().await;
dbg!("o1");
let _ = result_fut.await;
}
fn main() {
let rt = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(_main())
}
[src/main.rs:32:5] "o1" = "o1"
[src/main.rs:7:9] "d1" = "d1"
[src/main.rs:15:9] "d2" = "d2"
[src/main.rs:22:9] "d3" = "d3"
[src/main.rs:28:9] "d4" = "d4"
[src/main.rs:9:13] "f1a" = "f1a"
[src/main.rs:17:13] "f2a" = "f2a"
[src/main.rs:24:13] "f3a" = "f3a"
[src/main.rs:26:13] "f3b" = "f3b"
[src/main.rs:20:13] "f2b" = "f2b"
[src/main.rs:13:13] "f1b" = "f1b"
The non-awaited jobs are run concurrently as the moro docs say. But what if we immediately await f2?
[src/main.rs:32:5] "o1" = "o1"
[src/main.rs:7:9] "d1" = "d1"
[src/main.rs:15:9] "d2" = "d2"
[src/main.rs:9:13] "f1a" = "f1a"
[src/main.rs:17:13] "f2a" = "f2a"
[src/main.rs:20:13] "f2b" = "f2b"
[src/main.rs:22:9] "d3" = "d3"
[src/main.rs:28:9] "d4" = "d4"
[src/main.rs:24:13] "f3a" = "f3a"
[src/main.rs:13:13] "f1b" = "f1b"
[src/main.rs:26:13] "f3b" = "f3b"
f1 and f2 are run concurrently, f3 is run after f2 finishes, but doesn’t have to wait for f1 to finish, which is maybe obvious, but… (see below).
So two things here:
defer_to_scope()
be confusing if the job is awaited in the scope?I skimmed the latter parts of this post since I felt like I read it all before, but I think moro
is new to me. I was intrigued to find out how scoped span
exactly behaves.
async fn slp() {
tokio::time::sleep(std::time::Duration::from_millis(1)).await
}
async fn _main() {
let value = 22;
let result_fut = moro::async_scope!(|scope| {
dbg!(); // line 8
let future1 = scope.spawn(async {
slp().await;
dbg!(); // line 11
let future2 = scope.spawn(async {
slp().await;
dbg!(); // line 14
value // access stack values that outlive scope
});
slp().await;
dbg!(); // line 18
let v = future2.await * 2;
v
});
slp().await;
dbg!(); // line 25
let v = future1.await * 2;
slp().await;
dbg!(); // line 28
v
});
slp().await;
dbg!(); // line 32
let result = result_fut.await;
eprintln!("{result}"); // prints 88
}
fn main() {
// same output with `new_current_thread()` of course
let rt = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(_main())
}
This prints:
[src/main.rs:32:5]
[src/main.rs:8:9]
[src/main.rs:25:9]
[src/main.rs:11:13]
[src/main.rs:18:13]
[src/main.rs:14:17]
[src/main.rs:28:9]
88
So scoped spawn
doesn’t really spawn tasks as one might mistakenly think!
Because non-open ones are not available, even for a price. Unless you buy something bigger than the “standard” itself of course, like a company that is responsible for it or having access to it.
There is also the process of standardization itself, with committees, working groups, public proposals, …etc involved.
Anyway, we can’t backtrack on calling ISO standards and their likes “open” on the global level, hence my suggestion to use more precise language (“publicly available and sharable”) when talking about truly open standards.
Not only that. We don’t just “inject” raw strings with the
syn
/quote
duality. Stringified or not, the token tree will be parse-checked into the expectedsyn
type before being used in generated code.So the distinction is both wrong and irrelevant. This is what I meant by wrong on multiple levels/layers 😉