For going from C to Rust, I think you'd just use CString::to_str instead of CString::to_string. I'm pretty sure this just calls std::transmute behind the scenes and doesn't cause an allocation. (In the same way that you generally don't clone vanilla strings and instead pass references around.) iirc, it's still tricky to go the other way. I think if I was working with super C-FFI heavy code, I'd just end up using CString as my default for that code. Custom allocators would also help there, since you could just create the strings on the stack or whatever, but I don't remember if the string version of those is even finished in nightly yet.

You'd use CStr::from_ptr if you've received a C string (which does not allocate, that's correct, though not via transmute, just a cast), but since Rust strings aren't null terminated, you'll need to allocate some memory to add the null byte on the end. Which yeah, then I'd want to try to use CString as much as possible, in that case.

(If you wrote to an array on the stack, you could turn it into a Cstr too, instead of heap allocating, but then you'd have a max string size, which may or may not be something you'd want.)

alloc::string::String (a.k.a. std::string::String) doesn't support custom allocators yet, even on nightly, but that doesn't mean you can't use them; it just means you have to use a third-party crate, like https://docs.rs/string or https://docs.rs/smol_str.

imo, only if it's asked in bad faith. maybe that's just worded poorly, but e.g. "oh, thanks! what'd you do differently with this recipe?" or w/e

If I took the time to develop, write down and share a recipe, I'd welcome that question. Even if it's not original, there is variation among peach pies and I clearly have an opinion on it.

RTO in and of itself is hostile. Especially when there is still a highly contagious disease running rampant. It might not _legally_ constitute a hostile work environment, but it is _literally_ hostile.

Are you talking about covid, right now in August 2024? I wasn't aware that anyone was still living in fear of covid; my observation is that literally everyone, in every country has moved past it.

Sorry, didn't see your reply till now.

It's not literally everyone.

Immunocompromised people who have managed to survive are often still afraid of catching Covid. How little most people care means that those who are worried have a difficult time existing in public spaces. Especially with the constant social pressure to act like Covid is over. You're not going to see people who are worried about Covid as often, because... they are worried about Covid.

This was the case early on, too, though! Covid is _much_ more likely to kill people in marginalized groups. And while marginalized deaths still show up statistically, they are going to be more hidden in the day to day.

New Covid variants still cause severe long-term effects. From what I’ve read, the consensus seems to be “we have no idea what all of the long-term consequences will be, but they’re looking worrisome.” Covid is not reported on as much now, but this information isn't from like, fringe sources or anything. There is less news about Covid now because nobody wants to think or read about Covid anymore.

e.g. a quick search gives me: https://www.cbc.ca/news/health/researchers-are-still-untangl...

So, while most people may have moved on, I think the RTO movement is still hostile and coercive. Honestly, imo most people having moved on is also largely due to coercive forces.

i remember using the falstad sim constantly at university a decade ago. super helpful and so much more intuitive than any spice thing. cool to see that it's still around and used

this is what those end up being, it's pretty straightforward?

    fn five() -> i32 {
        return 5;
    }

    fn five() -> i32 {
        5;
        return ();
    }

semicolon changes the expression from returning the result of the expression to running the expression and returning the unit type. if you accidentally do that and specified a non-unit-return-type in the function signature, the type checker tells you about it:

    error[E0308]: mismatched types
     --> src/main.rs:1:14
      |
    1 | fn test() -> i32 {
      |    ----      ^^^ expected `i32`, found `()`
      |    |
      |    implicitly returns `()` as its body has no tail or `return` expression
    2 |     5;
      |      - help: remove this semicolon to return this value

which is also pretty clear about the solution

    let x = {
        3
    };
    let y = {
        3;
    };
    assert_eq!(x, 3);
    assert_eq!(y, ());

i think it'd also mean having to parse whitespace or newlines without something like that?

Thanks, I hate it. Is there any time where you want to use this? Like if Rust worked like other languages and just figured out if it was an expression or statement are there times where you would need an override?

I'm playing around with this in the compiler explorer and I'm now even more confused why you want this.

   let x = {
     println!("Don't mind me in the struct definition");
     3
   }
   assert_eq!(x, 3);

One of the things going on here is consistency.

It's not so much that this ability is specifically put in for some reason. It's just something that falls out of several other things.

Rust chose a "curly braces and semicolons" syntax because that's the sort of syntax that is normal in the sorts of PL spaces Rust wants to be used in. I am not sure exactly why being expression-oriented was chosen, but if I had to guess, it would be due to that just generally being considered a better option among many people at the time it was chosen.

So okay, you want expressions, and you want semicolons. Therefore, "you separate expressions with semicolons" is a pretty natural outcome. And since we're expression oriented, "a block is an expression that evaluates to the final value" is near tautological. And since it's an expression, it can go anywhere an expression can go.

Not being able to do this would mean creating specific restrictions against it, and then having to memorize when things don't follow the usual rules. That's more complicated than just letting expressions be expressions.

(also your let is missing a semicolon)

> I'm playing around with this in the compiler explorer and I'm now even more confused why you want this.

It works with RAII to create a temporally isolated resource scope, think context managers / using / try-with-resource; it provides a scratch space where you limit collisions with the rest of the function and avoid the risk of mis-reuse of those values; and before non-lexical lifetimes it was critical to limit borrow durations. It's also routinely used in combination with closures, to prepare their capture. Similar to C++ capture clauses, but without special syntax.

It's essentially a micro-namespace inside the function.

This kind of thing is useful for memory management. Anything you allocate within the scope that isn't returned gets dropped at the end.

You can use this to e.g. acquire a Mutex guard, move/clone something out of the mutex, and ensure it gets dropped as quickly as possible.

    let x = {
        let items = vec![1, 2, 3];
        items[1] // copied out of the vec since usize implements the Copy trait
        // compiler inserts drop(items) here
    };
    // items is no longer valid
    assert_eq!(2, x);

It also comes up in if/else blocks, which have exactly the same syntax and semantics (i.e. they are expressions, not statements):

    let condition = true;
    let x = if condition {
        println!("condition is true");
        5
    } else {
        println!("condition is false");
        10
    };
    assert_eq!(5, x);

edit: and of course, function blocks work exactly the same way! It's neat.

idk there are a lot of uses for it

    let dx = {
        let prev_x = x;
        x = get_x();
        x - prev_x
    };

often, it's slightly better cpp style scoping blocks if nothing else? there are tons of other little QoL things it enables though, but they're all going to be little ergonomics things that only seem worth it if you've used the language for awhile

Also common to set up "capture clauses" for lambdas as Rust does not have that in the language, IME most common with threads:

    spawn({
        let a = a.clone();
        let b = &b;
        move || {
            // do something with the a you cloned and the b you borrowed
        }
    })

is that a problem...? should a city not prioritize its citizens over random vacationers?

it happens for me if i click start now and try to use mouse button back, but if i click the back button it works? (also latest chrome)

i think you might lose people in the transition from the turing tape machine style bootstrapping to using full "words" for operations. it might help to compare it to something like regexes? (obviously they're not similar in the way that forth / stack langs are, but they're more commonly known and more commonly thought of as useful)

i think it'd also help a lot to have some gifs of the state machine operating on stuff

or maybe you could have something with "syntax" highlighting. a navigable timeline that changes the highlighting based on the current ignore lists and / or stack contents as you step through the code could be neat

"insultingly dumb, i listen to metal" "check this out, this top 100 musician isn't mainstream so you probably haven't heard of them"

this thread's turning into a decent example of why i hate talking to people about music. no matter how polite or reasonable someone is otherwise, there's like a 90% chance they have all these weird value judgements tied up in what people are listening to. it's incredibly tedious.

Some people view culture as a competitive sport.

Some people use pop culture trivia as the basis for their identity, get preoccupied by trying to prove they’re a ‘real fan’ to other people just like them and forget to enjoy any of it.

cue lightsaber sounds

Kindered soul here. People are way too aggressive about this stuff, and not even in an objective manner.

Tedious is the perfect word for it.