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 expected syn 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 😉

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 😉

I just looked at the code, and it's actually a neat idea implementation wise, and I see now how it helped you.

But I'm still of the opinion that its a purpose mismatch.

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.

• Pretending people write:

  let Ok(x) = read_input() else { return Err(Error) };
  

  instead of

   let x = read_input().map_err(|_| ...)?;
  

• Pretending people write:

   const x: &str = "...";
  

  instead of

   const X: &str = "...";
  

• Pretending there exist people who have such knowledge of rust macros hygiene, ident namespaces, etc, but somehow don't know about how macro code expands (the "shock" about the compile error).

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.

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.

If you're not into tiling, install openbox and a panel of your choosing. You will quickly find that you don't need a DE at all.

The maintenance is too high.

acquired knowledge spotted

I will let you on a little secret.

The best "support" you can get is support from upstreams directly (I'm involved in both sides of that equation). But upstreams will often only "support" you when you 1. run the latest stable version 2. the upstream source code wasn't patched willy-nilly by the packager (your distro).

So the best desktop linux experience comes with using rolling distro that gives you such packages, with Arch being the most prominent example.

The acquired knowledge that argues stability and tells you otherwise is a meme.

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.

• C++ offers no guaranteed memory safety.
• A fictional safe C++ that would inevitably break backwards compatibility might as well be called Noel++, because it's not the same language anymore.
• If that proposal ever gets implemented (it won't), neither the promise of guaranteed memory safety will hold up, nor any big C++ project will adopt it. Big projects don't adopt the (rollingly defined) so-called modern C++ already, and that is something that is a part of the language proper, standardized, and available via multiple implementations.

would you argue that it’s impossible to write a"hello, world" program in C++

bent as expected

This proposal is just a part of a damage control campaign. No (supposedly doable) implementation will ever see the light of day. Ping me when this is proven wrong.

The only (arguably*) baseless claim in that quote is this part:

it’s theoretically possible to write memory-safe C++

Maybe try to write more humbly and less fanatically, since you don't seem to be that knowledgable about anything (experienced in other threads too).

* It's "theoretically possible" to write memory-safe assembly if we bend contextual meanings enough.

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 Results than the other way around.

One can always wrap any code in {||{ //.. }}() and use question marks liberally anyway (I call them stable try blocks 😉).

I specifically mentioned HTTP/2 because it should have been easy for everyone to both test and find the relevant info.

But anyway, here is a short explanation, and the curl-library thread where the issue was first encountered.

You should also find plenty of blog posts where "unexplainable delay"/"unexplainable slowness"/"something is stuck" is in the premise, and then after a lot of story development and "suspense", the big reveal comes that it was Nagle's fault.

As with many things TCP. A technique that may have been useful once, ends up proving to be counterproductive when used with modern protocols, workflows, and networks.

They don't even run Android TV. They run a modified (normal) Android. This is well known, but the article also mentions it.