modulared

Looks like it was introduced in 1.81.0:

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

since the compiler cannot inline across await.

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.

Not having a required input, say when you try to reproduce a previous build of a package, is a separate issue to an input silently changing when you go to rebuild it. No build system can ensure a link stays up, only that what's fetched hasn't changed. The latter is what the hash in nix is for. If it tries to fetch a file from a link and the hash doesn't match, the build fails.

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.

That doesn't really make sense since memory safety is a property of a language. You can have code that is unsafe (read unsound), but that is a separate issue.

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.

I believe that languages with typestate can cause types to change as a result of function calls

Do you have any specific languages?

I could disable autoadding files, but life will be worse that way.

``` [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:
 ")

Why not just go talk the other people you'd really prefer to talk to?

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`.

To which language?

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<uint8_t>(Words::Foo) == 0);
    static_assert(static_cast<uint8_t>(Words::Bar) == 1);
    static_assert(static_cast<uint8_t>(Words::Baz) == 2);

Enums produce values. Tag-only unions 'produce' types (without values).

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?