Blocking work instead of comms.
And being open about it.
How obnoxious!

Here is an originally random list (using cargo tree --prefix=depth) with some very loose logical grouping. Wide-scoped and well-known crates removed (some remaining are probably still known by most).

mime data-encoding percent-encoding textwrap unescape unicode-width scraper
arrayvec bimap bstr enum-iterator os_str_bytes pretty_assertions paste
clap_complete console indicatif shlex
lz4_flex mpeg2ts roxmltree speedy
aes base64 hex cbc sha1 sha2 rsa
reverse_geocoder trust-dns-resolver
signal-hook signal-hook-tokio
blocking
fs2
semver
snmalloc-rs

Blog announcement.

--all-features doesn’t work with that particular crate because two of the features conflict with each other. The features list in my command is the one used for docs.rs from the crate’s Cargo.toml.

are there any hurdles or other good reasons to not just adding this to every create?

I’m no expert. But my guess would be that many crate authors may simply not be aware of this feature. It wasn’t always there, and it’s still unstable. You would have to reach the “Unstable features” page of the rustdoc book to know about it.

Or maybe some know about it, but don’t want to use an unstable feature, or are just waiting for it to possibly automatically work without any modifications.

Of course, I would assume none of this applies to the embassy devs. That Cargo.toml file has a flavors field, which is something I’ve never seen before 😉 So, I’m assuming they are way more knowledgable (and up-to-date) about the Rust ecosystem than me.

So, this is being worked on. But for now, that crate needs this line in lib.rs

#![cfg_attr(docsrs, feature(doc_auto_cfg))]

And this line in Cargo.toml’s [package.metadata.docs.rs] section:

rustdoc-args = ["--cfg", "docsrs"]

With these changes, feature gating will be displayed in the docs.

To replicate this locally:

RUSTDOCFLAGS='--cfg docsrs' cargo doc --features=nightly,defmt,pender-callback,arch-cortex-m,executor-thread,executor-interrupt

I constantly seem to include something from the docs, only to be told by the compiler that it does not exist, and then I have to open the source for the create to figure out if it’s hidden behind a feature flag.

As others mentioned, the situation is not perfect. And you may need to check Cargo.toml. Maybe even the source.

But as for the quoted part above, the docs should definitely indicate if a part of the API is behind a feature. Let’s take rustix as an example.

Here is the module list:

Here is the view from inside a module:

Here is the view from a function page:

This is also true for platform support. Take this extension trait from std:

Now, it’s true that one could be navigating to method docs in the middle of a long doc page, where those indicators at the top may be missed. But that’s a UI issue. And it could be argued that repeating those indicators over and over would introduce too much clutter.

Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.

Well, getters are not an official concept in Rust. You can do whatever works best in your case.

Just worth pointing out that a method with a return value of OptionᐸVecᐸStringᐳᐳ wouldn’t be really a getter, as you must be constructing values, or moving ownership, or cloning. None of these actions conceptually belong to a getter.

Also, you should be clear on the what the Option abstraction means. Does it mean the vector is empty? Does it mean the vector does not exist or some sort of null (FFI ore serialization contexts)? And make sure the code does what you expect it to do.

Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.

A vec and a string are basically the same thing (a series of bytes)

Everything is a series of bytes! I thought you were going to mention that both are fat pointers. But that “series of bytes” description is quite weird.

This makes handling it much easier because you can still iterate over it

This is not a valid consideration/objection, as Options are iterable and you can flatten them:

fn main() {
  let v = vec![1,2,3];
  for n in Some(&v).into_iter().flatten() {
    eprintln!("{n}");
  }
  for n in None::ᐸ&Vecᐸi32ᐳᐳ.into_iter().flatten() {
    eprintln!("{n}");
  }
}

This might involve the compiler making an allocation of an empty array but most of them (gcc, ghc) will now what you are doing and optimize the null check on the empty array to a bool check

This paragraph appears to be out of place in the context of a Rust discussion.

I will use the Rust Book first.

Good choice. Follow it with this Little Book of Rust Macros. And don’t verge into the unsafe stuff early, and don’t verge into it later unless it’s really necessary.

If you were on GNU/Linux, my answer to your questions would have had nothing to do with Rust. It would have involved tools like readelf and ldd, maybe strace.

So, maybe check out what equivalent tools exist on Windows, and try using them.

I only participated in two surveys, the first, then the second or third (don’t remember).

I am here. So, while I’m not sure, I think I’m still interested 😑

Maybe gauging level of interest based on the number of survey participants is not a sound strategy 🤔

I think there used to be a question about how long you’ve known/used Rust. And you would find that new or relatively new users were always overrepresented. Although, maybe that over-representation was read wrongly at times.

If I had to speculate something based on this decline, I would guess that most people who were to give Rust a try at some point, have actually done so already. So the influx of people new to the language, where for them the novelty (and the excitement/resentment that comes with it) hasn’t worn off already, has slowed down.

I’d say that’s understandable, and is to be expected after many years of hyped existence.

• I would drop the derive shorthands, and drop the Cypher prefix from the derive macros. They are already namespaced under the crate.
• Regarding the ty::new() impls, I’m not a hardline devotee of the builder pattern, but when there are multiple private fields of the same type, I would absolutely prefer it, to remove the possibility of field-value confusion at construction.

I didn’t dig deeper because I noticed you posted this to Reddit first 😉

Funny you should mention that. I think iced as of four days ago can do this!

If I’m reading the release notes and Cargo.toml right, cargo add iced --no-default-features and you should be good to go, as tiny-skia will be used as a rendering backend instead of wgpu.

Discriminant is irrelevant and you’re not supposed to fuck with it.

And there is zero reason to use unsafe/transmute for this.

pub enum LibErr {
    ErrX,
    ErrY,
    ErrZ,
    Unknown(i32),
}

struct RetVal(i32);

impl From for Result {
    fn from(RetVal(ret_val): RetVal) -> Self {
        if ret_val < 0 {
            match ret_val {
                -1 => Err(LibErr::ErrX),
                -2 => Err(LibErr::ErrY),
                -3 => Err(LibErr::ErrZ),
                unknown => Err(LibErr::Unknown(unknown)),
            }
        } else { Ok(ret_val) }
    }
}

// RetVal(call_function()).into()

I’m aware.

I just find calling the average proc-macro crate a “compiler plugin” a little bit baffling/confusing.

Isn’t the term “compiler plugin” reserved for crates/tools that depend on rustc, like clippy?

Oh, we are calling proc-macro crates “compiler plugins”! I didn’t realize.

Hello kornel.

Assuming you have the data, do you mind sharing how many crates in their latest version use compiler plugins?

Your aggressive tone is predictably inappropriate considering your failure at applying simple logic. You would only have a partial excuse if you’re 11y/o or something.

There is f-droid the app store, and f-droid.org’s main repo. See, it’s not that hard.

just because they have an app that allows you to add other repos doesn’t mean those other repos are a part of f-droid

And that app is called… get it?

Because those other repos are not f-droid repos

Repos made to work in the f-droid app are not f-droid repos… wow

Is the f-droid.org’s archive repo not an f-droid repo, too. lol.

Please tell me you’re not an adult!

The thing is, you started on the right track:

Sync is not open source and Fdroid only allows open source.

Here, you are on the right. And you could have followed up later by simply pointing out that “Will it be released to F-Droid” usually means “Will it be on f-droid.org’s FOSS-only main repo”, but you decided to rant some weird incoherent shit, and insisted on dying on a hell of straws instead!

Your information is a few years outdated. lineageOS neither comes rooted, nor does it offer a native way to root anymore. Magisk became a thing with a whole community around it. It’s an unlocked bootloader hider, root manager (and hider), and a system patcher, all wrapped up in one tool.

With Magisk, you give root access to the apps that need it, hide root ability from apps that require non-root devices (those apps do that by pretending to need root). Also, the Magisk app can rename itself, which is important as some apps check against the name itself.

The future challenge is with Google trying to force hardware identification (Apple style). I have not been following developments regarding that though, since as others mentioned, my X years old phone is still serving me perfectly, and I have no intention to upgrade any time soon.