Ok. SO. I guess Ill list the quizzes here.

Not really sure there is a lot to explain here.. Though, its strange cargo doesnt check for changes. That seems pretty basic. But I assume it means like. Never mind, I guess the wording is just a bit strange. It wont auto try to compile just from changes. That's fine.

No quizzes for 2.

Pretty boilerplate. x isnt mutable, mut is the keyword.. yada yada..

For a moment I thought a constant value sense it evals it a compile time it wouldnt allow math but. eh. just means it can be in global scope. Whatevs. Thats Ok.

Shadowing is weird. But it lets us do some neat things. In this case the shadow dies with the scope and it reverts.

fsize isn't a type. rip.

cant mix types because of memory. If you needed this you could make an array of an enum sense enums are part enum part union.

These kinda feel a little too "well yea, thats how its defined" to speak too much about it.

Not sure what to say. tbh..

I do kinda wish it did have 0 false all else true. But. whatever. That's ok.

sigh right. its saying 5 is the value, 10 of them. Right. Rust is weird.

Good to know if you take a look you can no longer submit something... You can have it. just don't use it.

Append appends. I don't know what else to say.

I mean, it explains it better then I can. Like, no sense in shortening that.

I see now that I was just not understanding there question. The function doesn't do anything. therefor, who knows what happens to it. It takes ownership and then instantly poofs the data. It doesn't borrow.

This is like, why, we like references. This is kinda the whole point.

This t is in charge now, s cannot change. that makes sense.

Borrowing is really just.. always finicky.

I dislike the borrow checker. thought this is really a design issue of the program. Silly cases don't make a lot of sense.

yea these don't compile because you guessed it.. the borrow checker.

These ones are really difficult because, this is like, the design of rust. To avoid these. So its really hard to think of what the syntax would be doing. To much abstraction for my C brain.

So, you can't do that.

clone is our friend. Just a shallow copy I believe.

it mutates the vector. So.. its needs to be mutable.

No reason to have primitive types on the heap. like, you wouldn't maloc a int. Why bother? So rusts abstraction isn't going to either. All things die from scope, so when there's a copy it goes kaput.

Ok you got me that time. I just thought, it must be an index out of bounds. But the compiler doesnt do that. Which.. ok fine. Thought that was the point but ok. The issue is that Rust doesn't know for sure that v[i] and v[i - 1] are referring to different elements. I.. I don't quite get that but uh. Sure. Ok.

Honestly I felt like I understood ownership more before this. Name now owns the input and thus dies. Without the rust analyser I cannot code rust for exactly this kinda thing.

yea because string has overhead. &str is bare minimum.

This has to do with knowledge of the function calls a little much for my taste. But that makes enough sense as its just a reinterpretation that needs a different interface.

This makes sense. that was the only one that was mut and didnt return.

doesnt show the whole thing fn find_contains(haystack: &[String], needle: &str) -> Vec<&String>; reminds me how 'a' == 'a' is ok in c but "a" == "a" isn't. because the second one sees if the memory segment is the same.

It obi needs unsafe code but this answer is more specific in why.

doesnt own because own lets you move. and.. well you can read the thing on screen.

Just.. kinda the definition.

frees on this function and its return value.

I don't like the notion that this can happen. Like. It cant know. But, it should be ok. So if you warped this in unsafe it would be fine.

Ok that tripped me up the ..a syntax but .. to a is just one so. thats fine. Should be a warning.. imo.. let me see.. Nope. not a warning. sigh

Different data members. Very glad this works this way.

ownership! uuuuggggh ok.

debug imo is also ya know. Faster to define.

p isnt a type. and new() is only a suggestion. neat. Of all things NOT to enforce though... why?

again this is like.. how to define things. Not sure what else to say.

dont copy when you dont need to but also it takes ownership because rust.

syntax works idk what you want me to say.

x takes ownership. Yay..

trying to put null. Nice try.

Not the point of option.

I don't like the syntax but. This is similar to drop through in C and better..sorta? Would have overhead without compiler optimization stuff.

I guess that's one way of one lining it. Sure.

Ownership changed.

Its pretty odd. but you could see how that's the same.

I like match but if there is nothing to match against. Of course.. you want if.

You say it rust book. you say it.

yea that would be bad. Darn borrow checker.

Copy on write is great.

I mean if you have the arguments at this point why not be able to change them. Tough.. if this was legit main, there's some fun problems there.

I sorta feel like unwrap should just be avoided as much as you can.

Not really sure what you want me to say anymore. Match is good.

Yep. that's what they are.

Thought if it were C we could make .o files we can compile faster by organizing code in development. From what I can tell. rust needs to make multiple passes through code and I dont think the borrow checker can cross check somethings usability so I don't think we get that.

mmhm that's the keyword.

The compiler doesnt know about that. bar isnt public.

A little convoluted but that's ok. Easy enough to follow.

why... sigh ok. Just because you can, doesn't mean you should.

It doesn't compile because the data members are not public.

that is the use keyword.

and, man. don't do that. Why does it even allow that?

Well where else would it be?

Ownership! again!

This one is a bit tricky but the important part from the one above is how its not weirdly recursive.

Its all bytes at the end of the day and &str cant be invalid. byte slice knows nothing.

Ownership again! muhahaha. I think you need to drop them or something I am unsure. either way still a design issue.

Im going to be honest, that one had me going for a bit. But mostly due to the de structuring.

remove requires mutable.

cant have more then one mutable handle at a time. Something like that?

We don't want to make a new vector and we also need to be able to index properly.

cant mut barrow something more then once and the compiler doesn't look if something is the same element only if it could be.

Honestly just none of them looked right.

This is actually kinda mind blowing. But it does make sense. But, I could just, know this. If it were C/C++.

Didn't know about that first one actually. Cool.

Cant pass around pointers for return so we have option (or result)

you need to handle errs option and err are not the same.

we probably wanna at least try to recover.

Ok ive done some reading and as far as I can tell.. I think it needs to be either usize or i32 or whatever the most general is. But I really don't know what it would be. and I cant find it mentioned in the article. So. Not sure. but thats the thing. I dont need to know. SO.. shrug

it asks for the value, the value is 3. nvm.

we cant assume anything

rust doesnt have function identity. I know. weird right?

you would think its bark(silence) but it sneaks a new line in there.

Imagine if you could just link any two things together in a stray file unrelated to these two things? That's why we wouldn't do that.

Im pretty sure this is basically a function pointer. so that makes sense.

it displays and it clones...

thats what they are... cant returrn something with different lifetimes

Long live static, long live the program!

needs to permiate the entire thing. How would it do it otherwise?

Ah neat. doesn't know what do with the syntax.

I wonder if its things like this why const correctness is never done correctly in c/c++ Obviously you need to have a mutable ting to sort it.

needs swap. cant edit in place.

not suppose to make a copy.

More ownership

That dang borrow checker making it so we cant have nice things.

Were internal so we can look at it directly and not mess up ownership.

That's how it works.

uuuuggggh. OK. fine. h is exclusive to the other test. though I cant say this is like that helpful. I don't feel like that should matter.

I would like to mention how, this is exactly the kind of thing we should be thinking about when organizing tests. like, Rust supports those test directories. But internal functions are also probably worth testing and knowing the limits of. So. There are things to think about here. IT should test interfaces not the real meat of something. At least that's my takeaway.

No quizzes in this chapter.

This makes perfect sense really. In terms of interface it should be clear by looking at a function what it takes and what it returns. Python is very frustrating due to this.

S gets moved into actually nothing. Aptly named.

That borrow checker is out to get ya.

The add is called after. Whats the point of that?

FnMut is more descriptive

Fn is the most acurate description still.

oh lovely...

Like.. sure..

Itterators are like that. its nice. Check out how for_each() in cpp works.

This was hard to follow, and I don't think I can make a shorter answer then there answer. Don't write code like this.

We don't do this one,

Or this one.

n gets copied and thus moves away.

More borrow checker shenanigans for ownership and stuff. I think threads absolutely need there stuff in arc. I cant find a good way not to at this point.

mpsc is a thing for sharing information between threads. its pretty cool.

we don't mutate unless we tell it to explicitly.

mutex unlocks when it goes out of scope.

arc is only atomic for the counter.

Send trait is the most valid.

That's just how it works. But no inheritance.

No inheritance. but like, again.

Don't do that.. why.. why would you do that? If your worried about compile time and binary size your using the wrong language.

What am I even doing anymore... Like. I think rust just wants to work simpler then this.

OK so these were failing to load properly so you just get them all in one chunk.

Ok. heres the first question

cant be mut

we weither RC or clone / copy over and over again.

if RC then you lose control over its allocation completely.