#Better way than "centralized" & mut T?

1 messages Β· Page 1 of 1 (latest)

stoic light
#

Since moving semantics are barely explained anywhere, and using RefCell doesn't sound hype, I decided to resort to only allowed way: one global mutref to modify vec itself and contents of its contents. Am I missing some cooler way to deal with it?
I am making whatever this is to train myself in various Rust concepts instead of linear things in vacuum.
https://github.com/randych-gilad/10-rooms

GitHub
GitHub - randych-gilad/10-rooms

Contribute to randych-gilad/10-rooms development by creating an account on GitHub.

loud niche
#

i assume the global &mut you're referring to is rooms_ref?

exotic oriole
#

if you can use rooms_ref without coming into any borrow checking issues then you can just replace it with &mut rooms

#

rooms_ref will absolutely become problematic if you need to have multiple reference to the rooms at once though

loud niche
#

yeah i just deleted rooms_ref and replaced all occurrences with rooms and it compiles fine

#

didn't even need to put &mut bc it was all method calls

honest lagoon
#

thanks folks, @stoic light asked me for advice on this, but I'm swamped with production work at the mo -
this sounds like just the sort of problem that tripped me up when trying to please the borrow checker early on, really good to talk about! 😁

stoic light
#

but what's more puzzling is that: am I supposed to ref it like that if I need to mutate both over and underlying data?

#

and I don't really want to get my leg wet with RefCell under such circumstance...

exotic oriole
#

The problem is without actual code your questions are very vague

#

it all depends on context with borrow checking, if you have a immutable borrow you just cannot mutably borrow at the same time

stoic light
#

right now you can see that &mut rooms is lava hot codepath if it can be called that
is there a way to sunder it into some more on-point refs or I'm doomed?

loud niche
#

wdym?

stoic light
#

or, you're saying that having so many things operate through single reference point is okay thing to happen?

loud niche
#

it's still a bit unclear what you're referring to, but i think so?

stoic light
#

majority of methods I have operate through the very same &mut rooms

loud niche
#

usually it's preferable to not create that, because then you can't create immutable &rooms references if you need them

stoic light
#

well, you can see I use the same mutref to do immutable operations
since I can't figure out a way to not do that

loud niche
#

yeah, that's why you shouldn't do that if you can avoid it

exotic oriole
#

it just doesn't make a lot of sense to do

stoic light
#

any ideas if I can avoid it in my case?
I fail miserably to see how

exotic oriole
#

calling methods on a value will not consume it if they take a reference

exotic oriole
#

like that's all you need to do really

loud niche
#

if you try to and it gives you an error, can you share that error with us? that would probably be more productive

stoic light
#

well, that advice indeed worked for no obvious reason, maybe I changed something since when I needed to introduce that

#

thanks for hinting this elusive thing

exotic oriole
#

it cannot be

#

you can obviously return a option

#

or you would have to store the value separately from the vec

stoic light
#

so more unwraps for unwrap god

exotic oriole
#

yeah

#

You could probably restructure the code and get rid of it

stoic light
#

I'm not sure what to return on None for these tbh, since can't ()

loud niche
#

you could return an Option<&mut Room>

stoic light
loud niche
#

not entirely sure what's unreliable about that?

exotic oriole
#

it will panic if it does not exist

loud niche
#

ah right

exotic oriole
#

but like

#

they verified the length

#

so

loud niche
#

ig i don't use that particular method enough to know it returns T and not Option<T>

stoic light
#

is there some, uh, nullable(?) thing I can do?

loud niche
#

that's what Option is for

exotic oriole
#

idk why try_remove does not exist tbh

#

but

#

for popping the first element

#

there is a way

#

and it's faster

stoic light
#

no, not VecDeque please

exotic oriole
#

ahaha

stoic light
#

it can't into sort_by

exotic oriole
#

aha

stoic light
#

I did consider it before

exotic oriole
#

Since VecDeque is a ring buffer, its elements are not necessarily contiguous in memory. If you want to access the elements as a single slice, such as for efficient sorting, you can use make_contiguous. It rotates the VecDeque so that its elements do not wrap, and returns a mutable slice to the now-contiguous element sequence.

#

you can use sort on mutable slices

stoic light
exotic oriole
stoic light
exotic oriole
#

slice.sort is a thing

slice - Rust

A dynamically-sized view into a contiguous sequence, [T]. Contiguous here means that elements are laid out so that every element is the same distance from its neighbors.

stoic light
#

which basically is the purpose of this whole project

exotic oriole
#

or well loot

#

Default will be None

loud niche
#

Option.take is a thing too

#

either works

exotic oriole
#

yeah

#

i forgor

stoic light
#

so you're saying that my 6th sense to put it all into option from get go was right πŸ€”

loud niche
#

Option is incredibly useful

stoic light
#

thanks, I've a good SLICE of things to think about

loud niche
#

hehe

stoic light
exotic oriole
#

slices are easy to use the problem is your mental model of what they are

loud niche
#

yeah, the great thing about Option is that it's so much safer than python's None

stoic light
loud niche
#

or java's null

#

or any of the million other nulls out there

exotic oriole
#

null is a fake concept made to sell more zeroes

stoic light
#

so my weak points are:
box
arc
refcell
arrays/slices
threads
closures

and I plan to combat them in this project

exotic oriole
#

refcells for another time maybe

stoic light
#

I'm looking at the code, at all the explanations of box
and no idea where to use it (reasonably)

exotic oriole
#

makes sense

#

you don't need it

stoic light
#

damn

#

is this some meme in the community?

exotic oriole
#

what part

stoic light
#

the box

loud niche
#

it's useful in certain situations

#

but in many cases it's not necessary

exotic oriole
#

it is more useful then RefCell let me tell you that

stoic light
#

everyone says "you will figure out Box when you need it"

#

nobody explains when

exotic oriole
#

exactly!

stoic light
exotic oriole
#

the biggest case will probably be for when you need to decide at runtime what trait to use

loud niche
#

^^^ that or recursive data structures

exotic oriole
#

oh OH

#

yes

stoic light
#

sounds cursed and sexy at the same time

exotic oriole
exotic oriole
stoic light
#

I sometimes feel that I'm in some limbo where every website is rustbook template

exotic oriole
#

mdBook

#

they are excellent

#

also made in rust

stoic light
#

I know about dyn!
I know it's something I don't need and it never works

exotic oriole
#

it's like bootstrapping, but with everything

#

not the dyn

#

if rust uses something it will be in rust (looks at git)

exotic oriole
loud niche
stoic light
#

damn I again behaved as if I have adhd or something

#

I wanted to ask about move semantics!

#

such as, what's the point of transferring stuff completely to another function or variable if you can just do what you want with it in place

loud niche
#

"in place" as in "by passing a reference"?

stoic light
#

like this Tris's example
it makes 0 sense to me

image.png
#

why should you give ownership to fn and discard variable you were operating with just fine

exotic oriole
#

if you are borrowing something that means it needs to last as long as the borrower

#

if you own something it will last as long as you do

stoic light
#

and EVERY example of moving is like that
confusing, concussing

#

no good showcase for something real

exotic oriole
#

think about vecs

#

why do vecs require ownership?

#

why do we not use Vec<&mut T> instead of Vec<T>

stoic light
#

no idea, hence I'm using &mut rooms exclusively

#

πŸ˜€ πŸ˜€ πŸ˜€

exotic oriole
#

&mut T needs T to be owned by something

#

a thing needs to own it

#

if we want to use Vec<&mut T> we have to make sure we never leave the function that owns the Ts

# 
fn i_own_the_ts() -> Vec<&mut T> {
  let (t1, t2, t3, t4) = todo!(); // whatever values here

  vec![&mut t1, &mut t2, &mut t3, &mut t4]
}
stoic light
#

wait, do I need a ref to take a slice?

exotic oriole
#

a reference to a vector will coerce to a slice reference

#

a slice without a reference is not a thing you can own

stoic light
#

ok so this won't work for me

#

but in my situation, what would I possible benefit from completely moving?
any ideas?

exotic oriole
#

wym completely moving?

#

it's hard without context

stoic light
#

or I need to call it "owner change" for it to be more understandable?

exotic oriole
#

yeah I'm still confused

#

show the code if you can

stoic light
#

sigh

#

once more

stoic light
#

any ideas if my code would benefit from something like this

exotic oriole
#

your current code, no?

#

if you needed it you would realize

#

it wouldn't really be an optimization

stoic light
#

in sense, I can't model and realistic scenario where I would need this

exotic oriole
#

more like, you would notice the compiler complaining

#

the most obvious case being a new function which returns the struct

#

if you are going to be making a struct you need to own the values

#

you are moving your ownership into the struct's ownership

stoic light
#

I understand why I would move ownership OUTSIDE the function
but not the other way around

exotic oriole
#

assumption: a reference may not last forever

loud niche
exotic oriole
#

ownership lasts for as long as you want, if you need something to last for as long as you want you need ownership

loud niche
stoic light
#

same thing with self - why if I can &mut self

exotic oriole
#

tbh the easiest way to find out about this

#

go to the rust documentation

#

pick a random type

#

and find a method without a reference

stoic light
#

nah not that
I can't come to realization on why would I my very self employ such practices

exotic oriole
#

because you need to make a struct which needs ownership Β―_(ツ)_/Β―

#

that is the simplest use case

#

for example Vec::leak and Vec::into_iter

#

into_iter takes ownership because it makes another struct using the Vec

#

leak does so because it wants to make the list last forever

loud niche
stoic light
#

well, I see it's not something obvious

#

because when I was asking something obvious it took you milliseconds to give examples

#

I will learn how to live with this

exotic oriole
#

it will not be hard to get used to

#

the default is to take ownership for a reason

#

aaa

#

ooo

#

option methods

#

those are a good example

#

things like map, and, or, and xor take ownership of the option because they want to transform it into another option

stoic light
loud niche
#

no, they return a new Option

exotic oriole
#

if you click the source button

#

you will see they are just match statements

#

map has a closure but that's about it

honest lagoon
stoic light
honest lagoon
#

rust has many sharp edges left to optimise, ergonomic fixes happen very often in releases, but we're all here because the REWARD of getting past these is freaking' insane πŸ˜„

stoic light
#

can we take a moment to appreciate rust-analyzer for making programming BORING?

honest lagoon
#

omg YES

#

and it understands the HTML macros in my web code just as well, my HTML life is just as boring

#

unclosed tags? impossible

stoic light
#

I mean, I've been coding 10rooms for whole weekend
how much times did I cargo run without knowing it will for sure run? 0

honest lagoon
#

so relaxing!

stoic light
#

I may at some point use it for more ambitious version of my ambitious project I will never complete because I don't know how