- 2023-10-01 18:45 **Alice 🌹:**
My list of pain points:
- no variadic generics, and the horrible error messages and limitations that produces
- having to install MSVC
- orphan rules
- object safety
- learning macros
- derive + phantomdata footgun
- cargo features aren't clearly listed in rustdoc
- lifetimes
- async

- 2023-10-01 18:49 **IceSentry:**
Someone asked about this recently, figuring out what default values actually are if they aren't in a doc comment can be a bit hard. Especially when you don't know the language.

- 2023-10-01 18:49 **IceSentry:**
I'd also say the `..default()` syntax (I don't remember what it's called) is sometimes confusing to some people

- 2023-10-01 18:53 **IceSentry:**
This would be less of an issue if bevy relied a bit less on this but since there isn't a shorter syntax to make things optional we're kinda stuck with it. Other than using builders for everything but that has it's own issues

- 2023-10-01 18:54 **Alice 🌹:**
struct update syntax

- 2023-10-01 18:54 **aevyrie:**
It would be less confusing if it wasn't recursive. E.g. if our public types had a manual default impl instead of deriving.

- 2023-10-01 18:55 **Alice 🌹:**
Oh, const being half-baked is annoying for beginners too

- 2023-10-01 18:55 **Alice 🌹:**
Especially float arithemetic and lack of const `Default`

- 2023-10-01 18:56 **Haddock:**
Sounds like a good list, eager to find out what those things mean

- 2023-10-01 18:57 **Alice 🌹:**
Ooh, docs.rs support for examples would help too: they're really valuable learning material and not exposed

- 2023-10-01 18:57 **Alice 🌹:**
Plus then you dodge the stupid "your examples are broken!!" problem

- 2023-10-01 18:57 **IceSentry:**
I'm pretty sure this is already being worked on

- 2023-10-01 18:58 **Alice 🌹:**
Yeah, some of the others (like the need for MSVC) are also being worked on 🙂 Prioritization info is useful though

- 2023-10-01 18:58 **IceSentry:**
I remember an RFC and partial impl of automatically linking examples using the function being docuemnted

- 2023-10-01 18:58 **Haddock:**
Shouldn't it be easy for RA or something to find out what a default actually is?

- 2023-10-01 18:58 **Alice 🌹:**
Yeah, but it also needs to show up on docs.rs

- 2023-10-01 18:58 **aevyrie:**
Yeah, could be solved with tooling

- 2023-10-01 18:58 **IceSentry:**
Yes but not everyone is using it. Having a solution built into docs.rs could be useful

- 2023-10-01 18:59 **Haddock:**
Well I am using RA and it doesn't have that feature (AFAIK)

- 2023-10-01 18:59 **IceSentry:**
Oh, I meant more like, yes RA *can* support it, not that it does support it

- 2023-10-01 19:01 **Haddock:**
I would be content if it did

- 2023-10-01 19:04 **Haddock:**
What are variadic generics? What is MSVC? How do orphan rules come up in Bevy? How does object safety? Yeah I can't do macros either. What's the derive + phantomdata footgun? I agree with features being unnecessarily unclear in rustdoc

- 2023-10-01 19:07 **s33n:**
I might have more later, but the one that pops to my mind is `Copy` on some types.
For example https://discord.com/channels/691052431525675048/1156841964214427649

> This `ghost.translation = Vec3::new(-100.0, -100.0, 0.0);` seems to do nothing

- 2023-10-01 19:10 **IceSentry:**
MSVC = MicroSoft Visual C/C++/Compiler
Not entirely sure of the exact acronym but it's something you need on windows for rustc to work correctly

- 2023-10-01 19:10 **Haddock:**
why is that a stumbling block? doesn't it just come with cargo

- 2023-10-01 19:12 **IceSentry:**
rustup can install it I think, but I guess some people don't like using rustup for whatever reasons

- 2023-10-01 19:15 **aevyrie:**
The rust install process on windows kinda sucks because you have to install MSVC, which takes forever.

- 2023-10-01 19:15 **WrongShoe:**
you already touched on these, but some additional context:
* lifetimes: passing system param to functions can be confusing, system params in generic and associated types are hard to know where to put your lifetimes.
* object safety rules can be annoying when you've already made your trait and now you need it to be dyn

* using dynamic linking with bevy leads to weird errors especially when updating libs/rust
* learning closure rules when things are captured by reference vs moving/copying. It feels very opaque what is a reference vs what is owned.
* I've seen people get tripped up on field init shorthand when building bundles

- 2023-10-01 19:15 **aevyrie:**
Trying to have a newbie get into bevy, they are likely on windows, and that process is much more painful than some other languages.

- 2023-10-01 19:18 **MrGVSV:**
Yeah object safety is a big one. Especially when users learn about trait objects and want to use it with `Component` and stuff.

Also seconding derive weirdness. Especially derives on generic types since those often add automatic, hidden bounds on the generic types

- 2023-10-01 19:29 **IceSentry:**
The target folder size and the fact that it keeps growing after each rustc update is also something that I see mentioned fairly often

- 2023-10-01 19:33 **WrongShoe:**
rust analyzer blocking cargo builds is annoying. I know you can change things, but this is the default behavior

- 2023-10-01 19:48 **WrongShoe:**
are there any resources on how to use docs.rs and rust analyzer to discover apis that might solve your current problem?

- 2023-10-01 19:52 **WrongShoe:**
just knowing how to "read the docs" is tricky for new users

- 2023-10-01 20:32 **nickrussell:**
There's a lot of art related stuff that game engines tend to present in a way similar to the art tools, and bevy does not do this yet. i.e. A Mesh in Blender is different than a Mesh under the hood of a Game Engine, and can make convos about it very confusing, as just happened in #rendering

- 2023-10-01 20:33 **IceSentry:**
While I agree, I think this is a strictly bevy related issue and there's not much rust can do about it

- 2023-10-01 20:34 **nickrussell:**
oh sorry i jumped the gun a bit there

- 2023-10-01 20:53 **Haddock:**
I don't think I can say anything useful

- 2023-10-01 21:01 **Griffin:**
Wait, you can change this!?!? :hoojBrain:

- 2023-10-01 21:10 **Trent (SleepyTea):**
Being able to view source on re-exported items in docsrs would be so useful

- 2023-10-01 21:17 **IceSentry:**
I don't remember if all of these are actually useful, but the general idea is to force RA to use a separate target folder

      "rust-analyzer.cargo.extraEnv": {
        "CARGO_TARGET_DIR": "${workspaceFolder}/target/rust-analyzer-cache"
      },
      "rust-analyzer.check.extraEnv": {
        "CARGO_TARGET_DIR": "${workspaceFolder}/target/rust-analyzer-cache"
      },
      "rust-analyzer.runnables.extraEnv": {
        "CARGO_TARGET_DIR": "${workspaceFolder}/target/rust-analyzer-cache"
      },
      "rust-analyzer.server.extraEnv": {
        "CARGO_TARGET_DIR": "${workspaceFolder}/target/rust-analyzer-cache"
      },
      "rust-analyzer.check.extraArgs": [
        "--target-dir=target/rust-analyzer-cache"
      ],

- 2023-10-01 21:18 **Griffin:**
aaah ok interesting

- 2023-10-01 21:19 **IceSentry:**
It has the nice side effect of making the target folder even bigger

- 2023-10-01 21:19 **IceSentry:**
Case in point, someone just asked about project size in #general lol

- 2023-10-01 21:22 **nickrussell:**
Wait is that why my builds stall on 'waiting for availability' or something all the time? I suspect alot of newbs like me don't even know whats causing it

- 2023-10-01 21:24 **IceSentry:**
I think that's mostly it yes but I'm not entirely sure

- 2023-10-01 21:42 **aevyrie:**
sccache would help in this case, you're basically building the same thing multiple times.

- 2023-10-01 21:42 **aevyrie:**
At least once the cache has been primed.

- 2023-10-01 21:45 **aevyrie:**
If cargo did something like this internally, it might help. I think you have to disable incremental compiles for this to work though.

- 2023-10-01 21:53 **nickrussell:**
oh that's a nice one. sccache was recommended to me, but i haven't had the time to figure it out, and abandoned it. I'm generally not sure if i can/how to get more time out of my builds and what drawbacks are. Doesn't seem clearly communicated. This is just my own perspective though, don't know if it fits the general population of new rust users.

- 2023-10-01 22:18 **IceSentry:**
I had issues with sccache in the past, but I started using it again lately and it's been alright

- 2023-10-01 22:34 **aevyrie:**
If you are looking for disk savings and caching, you can take the opposite approach as above, and point all compilation targets for all projects to the same dir.

- 2023-10-01 22:38 **aevyrie:**
(FYI, make sure to disable incremental compiles, or sccache can't do anything)

- 2023-10-01 23:57 **Gibonus 🐵🍌:**
Last time I installed rust on Windows, rustup did take care of MSVC. I mean the setup is as straightforward as it can be, rustup does install it itself, you just have to click two confirmation buttons.

- 2023-10-01 23:57 **Gibonus 🐵🍌:**
Also it has been a while since I was a rust beginner.

- 2023-10-02 00:01 **Gibonus 🐵🍌:**
The n#1 thing is the ridiculous error messages on erroneous traits for systems/system sets. I think it can be fixed in more ways than variadic traits. (The previously proposed solution of having custom error messages for trait errors is a good starting point)

- 2023-10-02 00:15 **Ole:**
There's also the fact that `[src]` doesn't show up in bevy docs, making it a lot more difficult to look at the source for something, which is marginally helpful in other libraries, but since a lot ofBevy is built using itself it's actually a big detriment that the source isn't easily available on docsrs

- 2023-10-02 01:15 **Gibonus 🐵🍌:**
At least @Alice 🌹 if you need to get someone to prepare a topic on how horrible are error messages for systems, I'm volunteering.

- 2023-10-02 01:23 **laund:**
one thing i personally struggled with when i learnt Rust through Bevy is finding implementers of a Trait across multiple crates.

things like "what's all the Components in my project, across all dependencies". even with just Bevy itself, while docs.rs does show all implementors, it's in a really hard to parse format which does things like repeat "impl Plugin for" over and over, making it difficult to skim over. a way to view that data with the order of information being Type name > Path > generics/bounds would be much better

- 2023-10-02 01:25 **laund:**
ideally i think this could be a R-A feature: a easily accessible table of all implementors which allows for searching and filtering them

- 2023-10-02 02:04 **Ole:**
This was already mentioned at the very top, but yeah, the message that shows up with invalid systems is absolutely horrendous, it's looks like a C++ template error just from sheer amount of text. That would definitely be cleaner with variadic generics (since there should just be one impl, instead of like 16), but I think that's actually suffering from more than just that, since there's no way to know which part of the resulting tuple is wrong anyway. Not sure if this is even solvable, but I do think maybe a custom trait bound error could help at least (mostly if you get to say "double check each parameter is a valid systemparam", but if you could go even further and dig into each part of the tuple and provide more fine-grained "this type is not a valid systemparam", that would make it even better

- 2023-10-02 02:14 **Gibonus 🐵🍌:**
I mean, if it can be done with a macro (like in `bevycheck`), it can be done by the compiler. The logic for it would be "if error comes from the type being a tuple/`Fn`, and the trait it tried to match is a tuple/`Fn`, then check for traits implemented by the arguments/tuple. etc. Fine for a compiler error as an "after-the-fact" error.

- 2023-10-02 02:17 **Ole:**
Mhm, also I just noticed you already mentioned this, oopsie

- 2023-10-02 02:29 **iyes iða 🧊:**
speaking of ...

- 2023-10-02 02:30 **iyes iða 🧊:**
there are a few docs.rs-related issues that IME a lot of ppl run into

- 2023-10-02 02:30 **iyes iða 🧊:**
both of which can be resolved by building and using offline docs locally with `cargo doc --open`

- 2023-10-02 02:30 **iyes iða 🧊:**
but ppl don't know that

- 2023-10-02 02:31 **iyes iða 🧊:**
IME most ppl dont know that they can build offline docs that are exactly like docs.rs but *better* because they include their whole deps tree and everything in the docs actually works and is linked to correctly; ppl tend to be very surprised/impressed when i teach them how to build their own docs

- 2023-10-02 02:31 **iyes iða 🧊:**
but anyway

- 2023-10-02 02:32 **iyes iða 🧊:**
the issues im taking about are

- 2023-10-02 02:33 **iyes iða 🧊:**
1) for whatever reason (i think it has something to do with the stuff we do to make `bevy_dylib` work, for dynamic linking), source code is not included in docs.rs

- 2023-10-02 02:33 **iyes iða 🧊:**
unlike for other crates, there are no `[source]` links when you browse Bevy's docs on docs.rs

- 2023-10-02 02:33 **iyes iða 🧊:**
my usual way to figure out what the default values are for something is to click on the source link

- 2023-10-02 02:34 **iyes iða 🧊:**
that way the API docs in the browser take me straight to the Default trait impl and i can see what it does

- 2023-10-02 02:34 **iyes iða 🧊:**
but that is not available for bevy

- 2023-10-02 02:34 **iyes iða 🧊:**
unless you build offline docs

- 2023-10-02 02:34 **iyes iða 🧊:**
i frequently use those source links myself, and IME a lot of ppl seem to glance over them and never use them even for other Rust crates, where they do exist

- 2023-10-02 02:35 **iyes iða 🧊:**
ppl arent aware enough of their usefulness

- 2023-10-02 02:37 **iyes iða 🧊:**
2) docs.rs struggles when APIs use public types from external crates/dependencies

for a quick example of this, try going through the docs for various things in `bevy_render`, where they use `wgpu` types (that aren't re-exported by `bevy_render`). Those types cannot be clicked on, they are not rendered as links.

- 2023-10-02 02:37 **iyes iða 🧊:**
if you build offline docs, you have docs for your entire dep tree, and that means you can jump straight into the wgpu docs whenever you click on a wgpu type that appears in the Bevy API somewhere

- 2023-10-02 02:38 **iyes iða 🧊:**
ive also encountered this with Rapier and other math/physics plugins

- 2023-10-02 02:39 **iyes iða 🧊:**
they will use types from their backend physics/math engine, but when you browse the docs of the bevy plugins, you cannot navigate to the docs for those types

- 2023-10-02 02:39 **iyes iða 🧊:**
on docs.rs

- 2023-10-02 02:42 **iyes iða 🧊:**
3) people get very confused around Traits and how they are rendered in API docs

it is often very difficult to figure out, say, what methods are available on a type, when you have things coming from many different traits. this is a big problem with bevy, because the bevy_ecs and bevy_app apis are very trait-heavy

i know how to navigate the api docs' trait listings to try to build a mental image of what types provide what apis via what traits, but i admit this is a very specific skill i have gained with a lot of rust experience, and to new rust users the experience seems very very arcane

- 2023-10-02 02:44 **iyes iða 🧊:**
it also doesn't help that, due to the lack of variadic generics, many of our docs are polluted with bogus impls of a trait for every possible tuple up to some arbitrary length

- 2023-10-02 02:44 **iyes iða 🧊:**
you have to mentally filter out all that noise

- 2023-10-02 02:45 **iyes iða 🧊:**
if you want to look at the docs for, say, types that impl Bundle / SystemParam / WorldQuery / whatever

- 2023-10-02 02:58 **Ole:**
I didn't even know that

- 2023-10-02 03:00 **Ole:**
I'm pretty sure it's just due to the re-exporting. I was trying to fix this bug a while ago because it was bugging me, but it turned out to be beyond my skill, and required quite a bit of design work across cargo and rustdoc and docs.rs that I struggled to comprehend

- 2023-10-02 03:55 DJMcBavy: My approach on the big target directories is to use a ramdisk for them
Because I think it's worth the jankiness and recompilation every time I reboot to avoid needing to think about cleaning up target directories across all my projects

- 2023-10-02 04:29 **Alice 🌹:**
Variadic generics are the "I want to have tuples of arbitrary length in the type system" thing that Bevy fakes for queries and system parameters

- 2023-10-02 04:30 **Alice 🌹:**
Orphan rules come up a lot with Component/Resource/Event/Reflect derives on third-party types

- 2023-10-02 04:31 **Alice 🌹:**
Object safety doesn't come up directly, but when users start playing with trait objects there's a very harsh and confusing wall

- 2023-10-02 04:32 **Alice 🌹:**
The PhantomData footgun is where you derive e.g. Clone on a type that contains a PhantomData. But it won't work for types where the generic type doesn't implement Clone, even though you can clone *any* phantomdata type

- 2023-10-02 07:14 **iyes iða 🧊:**
there is another related PhantomData-related pitfall

- 2023-10-02 07:15 **Haddock:**
Is there no way for Rust to squiggle the specific system that doesn't fit rather than the whole tuple

- 2023-10-02 07:17 **iyes iða 🧊:**
Rust doesn't allow you to have a generic type parameter on a struct, that is unused. which means that if you want to have, say, marker components or system sets that are parametrized by a type, you cant do that easily

- 2023-10-02 07:23 **iyes iða 🧊:**
for example, in my game, i have two types that i use to represent coordinates: `Hex` and `Sq`, and a trait that lets me make game logic that is agnostic to the map topology. I want to write systems like:

  fn my_game_mechanic<C: Coord>(
      q_tile: Query<(&TileCoord<C>, &Stuff)>,
  )

and then add two instances of that system, for each coord type. Ideally with run conditions, so that only the correct variant runs, depending on the map type:

  app.add_systems(Update,
      my_game_mechanic::<Hex>.run_if(map_topology::<Hex>),
      my_game_mechanic::<Sq>.run_if(map_topology::<Sq>),
  );

But if I want to create a system set, I can't do that easily:

  #[derive(SystemSet, Debug, Clone, Copy, PartialEq, Eq, Hash)]
  struct MapTopologySet<C: Coord>;

doesn't work, because the `C` type parameter is unused. I have to add a phantom data into the struct, which makes it very annoying/ugly/boilerplatey to use.

Same if I want to create a component type that I want to parametrize, so it can behave differently (by using associated functions in the Coord trait) in systems depending on the map topology:

  #[derive(Component)]
  struct TileExplosionAnimation<C: Coord>;

(would need phantom data)

- 2023-10-02 07:43 **Ole:**
There is https://crates.io/crates/ghost-lite which might work

- 2023-10-02 11:21 **🫠:**
2 weeks on rust + bevy, coming from unity:
most of that time was spent stopping what I'm doing to go through documentation / example / source code.
so from my perspective, the biggest problem *as a new user* is that rust/bevy requires too much upfront knowledge to make something.

- 2023-10-02 12:51 **iyes iða 🧊:**
one more thing to add to your list: reborrowing

- 2023-10-02 12:51 **iyes iða 🧊:**
and all the general papercuts around referencing/dereferencing stuff

- 2023-10-02 12:51 **iyes iða 🧊:**
especially around "smart pointer" types like `Mut` and `Res`/`ResMut`

- 2023-10-02 12:51 **Alice 🌹:**
Oh yep

- 2023-10-02 12:52 **IceSentry:**
Oh yeah, having an actual new type pattern would be great

- 2023-10-02 12:52 **IceSentry:**
Tuple struct work, but spamming .0 everywhere is not new users friendly

- 2023-10-02 12:52 **Alice 🌹:**
What sort of learning material would help you there? Detailed tutorials? Game dev specific advice?

- 2023-10-02 13:30 **🫠:**
tutorials could make it smoother, but you can frequently see that beginners tend to copy the tutorials without learning from them.
rustlings' approach for testing knowledge is good for catching that, but the examples are boring.
so it's worth trying that, but with interesting examples.

- 2023-10-02 13:31 **Alice 🌹:**
Yeah, something like Rustlings but for games is really appealing

- 2023-10-02 14:30 **Haddock:**
I've suggested this before: there ought to be a deref trait with the right semantics for newtyping

- 2023-10-02 14:31 **Haddock:**
I hate abusing deref for it but I also hate not using deref

- 2023-10-02 14:32 **Haddock:**
but by the time Rust agrees on anything like this, Bevy will be fully released

- 2023-10-02 14:33 **Haddock:**
I guess it doesn't have to be a trait, and maybe it's better if it's not

- 2023-10-02 14:34 **Haddock:**

  Newtype UserList(Vec<User>);

- 2023-10-03 12:34 **testare:**

I had the same problem. Deref helps, but then I have to use double stars everwhere. So I created some custom query parameters `AsDerefMut<T>`, `AsDerefCopied<T>`, etc. so that they were automatically dereferenced in the query, which I've personally found quite nice. I created a crate called `bevy_query_ext` so other people could use them, though I'm not sure how user friendly it is

- 2023-10-03 12:35 **IceSentry:**
That's an interesting work around but it's also an even stronger argument as to why we need this built into rust 😅

- 2023-10-06 01:29 **Bas | eXoSpace Combat Engineer:**
Coming from other languages (Java, C# mainly), it took me quite some time to get used to the borrow-checker. It has become much easier to use over time, however. Also, having internalized thinking about ownership helps a lot. I think that learning effort is unavoidable and actually really valuable. There's good guides for that as well.

My biggest obstacle is lifetimes, which I really cannot wrap my head around. It's just too many silly signs and annotations for me to grasp while looking at the core. Lets say: too much cognitive complexity for me. So I avoid usimg them altogether, which works for me. I'd be happy if they were needed in fewer cases.

Finally I struggle with the slow feedback from rust analyzer or other tools. I'm used to getting instant feedback from the IDE (IntelliJ, Java) when I do something wrong. This just takes longer, whether I use RustRover or VSCode.

- 2023-10-06 01:29 **Bas | eXoSpace Combat Engineer:**
But overall I'm quite a happy Rust user, it's a great language.

- 2023-10-06 01:37 **Ole:**
Do you have autosaving turned on in vscode? Rust-analyzer doesn't have many checks that run on unsaved code, which is a thing they're actively working on, so for now you basically have to save the file for rust-analyzer to update, but in my experience it's very quick to respond after you've saved, but maybe it's not for you?

- 2023-10-06 01:38 **Ole:**
Though this was a big source pain for me, because I was used to my LSP giving feedback immediately, so having it only respond after a save was very unintuitive to me

- 2023-10-06 01:42 **Bas | eXoSpace Combat Engineer:**
I do have auto saving active (by default) in RustRider. There may be an issue with my system setup (or just a somewhat slower CPU)

- 2023-10-06 07:26 **Haddock:**
I assume you've read things on lifetimes as well, but I wanna try anyway. it's at its core just saying this won't outlive that. the simplest example is, say you have a method that strips any leading instances of a string slice (`&str`), you pass, from another `&str` you pass, and returns the rest of that first string slice (let's say it just returns it unaltered if the prefix wasn't there)

  fn strip_prefix(text: &str, pattern: &str) -> &str {

would be the signature

- 2023-10-06 07:27 **Haddock:**
however, Rust doesn't know *which* reference the new string slice reference relates to. which reference it can't outlive. is it the pattern or the text?

- 2023-10-06 07:39 **Bas | eXoSpace Combat Engineer:**
Thanks for trying 😉 I can see how using lifetimes in that situation would be better performance-wise, but in this case I would simply clone the string and use that. But that is how Java does it, so its just what I am used to. Maybe I'll try using lifetimes again and see if I understand them better now.

- 2023-10-06 07:45 **Haddock:**
aside from being worse performance, cloning is not always possible at all

- 2023-10-06 07:46 **s33n:**
I often find myself doing the same thing 😅 Especially during experimentation when I'm not quite sure what a given piece of data should look like, trying to use lifetimes more often than not shoots me in the foot, introducing constraints that I end up spending more time trying to work around when my requirements change at all

- 2023-10-06 07:47 **Haddock:**
anyway, in the above example, we tell Rust

  fn strip_prefixes<'t, 'p>(text: &'t str, pattern: &`p str) -> &'t str {

and bam it knows

- 2023-10-06 07:47 **Haddock:**
it just wanted to know

- 2023-10-06 07:47 **Haddock:**
not sure I wrote that correctly xd

- 2023-10-06 08:05 **Ole:**
Ya did 😋

- 2023-10-06 11:27 **Bas | eXoSpace Combat Engineer:**
So this means: "the return value lives as long as the `text` parameter you passed", right? And the `'p` lifetime is added just because everything needs a lifetime once you add one, or is there another reason?

- 2023-10-06 11:28 **Haddock:**
Lives *no longer* than the text parameter you passed, the borrow checker will make sure of that

- 2023-10-06 11:28 **Haddock:**
it's allowed to live shorter

- 2023-10-06 11:28 **Haddock:**
and yes, basically you need lifetimes everywhere, but for simple cases, like no outputs with lifetimes, or only one input and one output with a lifetime, it will infer and do it for you

- 2023-10-06 11:29 **Haddock:**
everywhere there is a reference*

- 2023-10-06 11:29 **Bas | eXoSpace Combat Engineer:**
Ah yes, I understand, thanks

- 2023-10-06 11:29 **Haddock:**
By the way, the inference can be wrong

- 2023-10-06 11:29 **Haddock:**
when it's wrong it will be stricter than it has to be

- 2023-10-06 11:37 **Haddock:**
for example, imagine a function that looks through a list of constant str slices, and finds the one that is most similar to an input str by whatever algorithm, and returns it

  const MY_STRINGS: [&str; 10] = ["Hello", "Hey", "Test", etc.];
  fn pick_string(input: &str) -> &str 
    let seed = rng::Seed::from(input);
    MY_STRINGS[rng::random(seed, 0..10)] // most excellent algorithm
  }

- 2023-10-06 11:38 **Haddock:**
it will be pessimistic about the lifetime of the return value

- 2023-10-06 11:39 **Haddock:**
not sure the best example xD

- 2023-10-13 13:24 **Haddock:**
I can't get over this idea to allow us to flag a type as inherently *for* mutation, like `&mut`, causing it to be treated as mutable without needing a keyword

- 2023-10-13 13:24 **Haddock:**
Would it be too crazy to ask this of Rust?

- 2023-10-13 13:30 **Alice 🌹:**
I think this falls under "effect system" 🙂

- 2023-10-13 13:33 **Haddock:**
Hmm?

- 2023-10-13 13:34 **Alice 🌹:**
https://boats.gitlab.io/blog/post/the-problem-of-effects/

- 2023-10-13 13:38 **Haddock:**
I don't see it

- 2023-10-14 03:11 **iyes iða 🧊:**
@Alice 🌹 has the meeting (that you talked about in the OP of this thread) already happened?

- 2023-10-14 04:21 **Alice 🌹:**
No, haven't heard back yet 🤷‍♀️

- 2023-10-14 06:42 **Ole:**
Also you mentioned joining the meeting, is there a requirement for that? I'm not sure how much I personally would be able to contribute, but I'd love to join in case I do have something useful to contribute 😇

- 2023-10-14 06:44 **Alice 🌹:**
No requirements for that ❤️

- 2023-10-15 08:16 **Josh:**
Sorry for the delay in following up on this; I'm currently (still) traveling. I filed https://github.com/rust-lang/lang-team/issues/229 about scheduling a design meeting.

- 2023-10-15 08:17 **Josh:**
Thank you @Alice 🌹 for starting this thread, and thank you to *everyone* who contributed; I'm reading through the thread, and I look forward to going through these with the lang team in more detail.

- 2023-10-15 08:17 **Josh:**
Some of them are on our list but haven't been at the top of the list, and some of them are news to me, at least.

- 2023-10-15 08:17 **Josh:**
❤️

- 2023-10-15 08:21 **Alice 🌹:**
I'm really glad we could help out!