https://blog.rust-lang.org/2024/09/05/Rust-1.81.0/#new-sort-...

Is this stated somewhere? A simple search online yields nothing, and just testing it out on godbolt the compiler does inline at least simple async functions as mentioned in the article.

Flakes, then, run in a pure evaluation mode, meaning you don't have access to stuff like the system triple, the current time, or env vars and all fetching functions require a hash.

For a language to be memory safe it means there must be no way to mishandle a function or use some object wrong that would result in an "unsafe" operation (for Rust, that means undefined behavior).

That is to say the default is safe, and you are given an escape hatch. While in something like c/c++ the default is unsafe.

I'd also like to add that program correctness is another separate concept from language safety and code safety, since you could be using an unsafe language writing unsafe ub code and still have a correct binary.

Do you have any specific languages?

``` [snapshot] auto-track = 'none()' ```

This is what I do, and I don't think it is worse. I prefer not having all my ignored files auto-tracked when I accidentally go back to a commit without them in the .gitignore

Some other solutions (which aren't simple at all): - Remove specific files from auto-track - Have a private commit with changes to the .gitignore and work on top of a merge commit - Like last one, have a private commit with the files you don't want to push (+ merge)

I have it setup where any commit with a description that starts with "IGNORE:" is private.

snippet from my config: ``` [git] private-commits = ''' description(regex:"(?x) # (?x) enables the x flag (verbose mode) allowing comments and ignores whitespace # see: https://docs.rs/regex/latest/regex/#grouping-and-flags

  # Ignores commits starting with:
  # (case-insensitive) PRIV: or PRIVATE:, or IGNORE:
  ^(?i:PRIV(ATE)?):
  | ^IGNORE:
 ")

sorry, I didn't mean to be so argumentative or negative. (The "You'll have to ask the Rust community. Rust lacks enums." did get me a little annoyed :p)

> This (strangely, undocumented in the above link) functionality does, in fact, provide the use of enums.

That link was from "the rust book" which is primarily is for learning rust. For more technical info the referenced is used https://doc.rust-lang.org/reference/items/enumerations.html

> When would you ever use it?

I assume (like you said for c++) a good reason would be for c/c++ interoperate, but it also probably makes things like serialization easier. Sometimes you just need a number (e.g. indexing an array) and it's simpler to be able to cast then have a function that goes from enum -> int.

> Especially when you consider how unsafe enums are.

Do note though, going from int -> enum is an unsafe op which would require `std::mem::transmute`.

I mean more in the sense of "where did you get this definition from."

> The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class.

I'm still not seeing a difference, mainly because when I went to see how c++'s `enum class` and rust's `enum`, they both seemed to work the same.

    #[repr(u8)]
    enum Words {
        Foo = 0,
        Bar,
        Baz,
    }

    const _: () = {
        assert!(Words::Foo as u8 == 0);
        assert!(Words::Bar as u8 == 1);
        assert!(Words::Baz as u8 == 2);
    };

    enum class Words : uint8_t {
     Foo = 0,
     Bar,
     Baz
    };

    static_assert(static_cast(Words::Foo) == 0);
    static_assert(static_cast(Words::Bar) == 1);
    static_assert(static_cast(Words::Baz) == 2);

Source? Is this something that is widely accepted, or just how you think enums should be defined.

My understanding is you are saying (using c++ as an example since it has both types) an `enum` is a "true" enum, while an `enum class` somehow isn't?