[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: pepe_notes.jpg (91 KB, 735x542)
91 KB JPG
so I have been learning rust, and finally getting hold of its features and basic ideas, something that I have understood are as follows
>shadowing doesn't actually cause the original varible to go out of scope, just makes it inaccessible through its name, takes it for itself
>variables have scope, values and references to them have lifetimes
>lexical scope of variable ends at the closing curly brace of the block it exists in.
>lifetime of a reference ends at its last usage.
>>
wtf, I didn't subscribe to your blog, why am I seeing this?????
>>
>>109594216
have you seen /dpt/ yet? If not, maybe use the search function. Closing this thread now
>>
>>109594216
Keep at it anon!
>>
File: code.jpg (121 KB, 720x1047)
121 KB JPG
>>109594449
thanks man
>>
>>109594216
there is no such a thing as "variables". you have "let bindings", which are names for values, owned or borrowed.
so not sure what you're talking about. and you should have much better command of the basic terminology.
>>
>>109594827
dumb retard
https://doc.rust-lang.org/reference/variables.html
>>
>>109594840
this is """memory model""" terminology, not a type system semantic one. but it is used in the reference, yes.

and what you should have actually linked is:

https://doc.rust-lang.org/reference/names/scopes.html#r-names.scopes.pattern-bindings

luckily for you, the "local variable" terminology (from the memory model) is still mentioned here.

that "Names" section got added in v1.51, and i don't like how "memory model" terminology is used without always linking to the memory model section, like in statements sections. but tbf, the reference is not meant to be "learning material" in any case.

what a beginner should really focus on in that part of the language is learning the namespaces, unless the learner is completely oblivious to very basic low level constructs like stack frames. in that case, they should go learn C first, even if at a basic level.
>>
>>109594253
>mfw /g/ has people actually interested in technology
>>
>>109595441
nobody cares what you think is appropriate terminology
>>
>>109594216
you will never be a woman
you will never be a real programmer
>>
File: calendar.png (3.16 MB, 9779x3472)
3.16 MB PNG
>>109595544
wrong
>>
>>109595561
useless masturbation. where are your actually useful programs, you mentall ill borrowchecker masturbator
>>
File: calendar.jpg (3.92 MB, 7997x4450)
3.92 MB JPG
>>109595590
>>
>>109595606
useful
>posts more useless masturbation
lmao, you are low iq af
>>
File: calendar_small.jpg (3.99 MB, 7907x5941)
3.99 MB JPG
>>109595629
how about this?
>>
>>109595630
>useless masturbation
nah, still not a real programmer
>>
File: var.png (31 KB, 1069x331)
31 KB PNG
>>109595466
>what you think
retard!
>>
>>109595803
yes, that's what I linked, dumb retard
>>
lifetime of a reference is just the scope for which it is valid, thing is scope of a variable is completely lexical, it always ends at the curly brace, while references can go out of scope earlier, thanks to NLL (non lexical lifetimes), basically rust compiler is only interested in making sure that reference to a value in memory doesn't outlast the memory itself.
>>
File: mm.png (97 KB, 2740x846)
97 KB PNG
>>109595824
retard!

The memory model is neither fully decided, nor is it actually a part of the core language. The Linux kernel doesn't even follow it, although the differences are obviously not at the (local variable is a value living in a function stack frame) level.
Also, the memory model as a whole is largely copied from C++, but that covers details not mentioned in the reference (atomics and shit).
All the reference is covering here is literally the very basics of byte, heap, and stack, which would only be useful to a complete tech illiterate. The only thing mentioned outside of those is "provenance", with a link to where the topic is actually documented (the ptr core type).
And none of this has anything to do with Rust semantics or type system.
If you don't know what a call stack value is, which is what "local variable" is strictly referring to here, then you have no business learning rust in the first place.
>>
File: img-2026-08-19-16-40-47.jpg (1.03 MB, 1202x4889)
1.03 MB JPG
>>109596127
who are you on the compiler team?
oh, you are a nobody?
dumb retard!
>>
>>109596058
rust doesn't guarantee `Drop`s happening at the curly brace. how things work now can change in the future, just like how they changed with references and NLL.
this is exactly why i hate the confusion "memory model" introduces to understanding actual rust semantics.
>>
>>109596156
retard!
you should have linked the language team.
>>
File: img-2026-08-19-16-46-59.jpg (118 KB, 1197x636)
118 KB JPG
>>109596168
who are you on the language team?
oh, you are a nobody?
dumb retard!
>>
>>109596198
good progress.
still fallacious, but at least points to the right people.
>>
>>109596216
wrong, dumb retard
>>
>>109596158
dude drop() is only called on values with type that implement the drop trait, there is no need for such a guarantee, drop() is not concerned with stack frames.
>>
>>109596220
yes. you totally btfo'ed me izzat boy. accept my concession and complete obliteration, and go celebrate with your family.
>>
>>109596250
I accept your concession, dumb retard.
>>
>>109596245
we are discussing rust semantics for people learning the language. neither a "Copy types exist" gotcha, nor this general leakage of educational abstractions, is helpful. that's my point.
>>
>>109594216
I'm glad you understand fren
>>
>>109596257
failed impersonation
>>
>>109596266
dumb retard!
>>
>>109596279
see >>109596156 and >>109596198
dumb retard!
>>
>>109596292
you can relax izzat boy. you already WON.
>>
File: te'alc.jpg (30 KB, 390x512)
30 KB JPG
>>109596307
>>
>>109596058
>lifetime of a reference is just the scope
nope, scope refers to a region within the code, lifetime refers to a period during code execution, basically the span of time for which a reference to a value is guaranteed to be valid, old rust (pre 2018) did not have NLL, this caused false positives, perfectly fine code didn't compile cause lifetimes lasted the entire block, and you couldn't make any further writes to the underlying data, even if that reference had no further usage it still kept existing.
>>
>>109594216
>shadowing doesn't actually cause the original varible to go out of scope, just makes it inaccessible through its name, takes it for itself
Yup. In general values are kept around until they aren't needed anymore. Compiler can drop a variable mid function if for example it holds a borrow on something but is no longer used and you need the borrowee for something. You can also drop any variable at any place using drop() function.

>variables have scope, values and references to them have lifetimes
>lexical scope of variable ends at the closing curly brace of the block it exists in.
>lifetime of a reference ends at its last usage.
Yea, but now we have non lexical lifetimes so the lexical scope doesn't really matter much. Especially with the new solver, lifetimes can really stop at random places or only affect certain code branches etc. I don't think you should really pay too much attention to how scopes and lifetimes relate, these things change and compiler will give you good hints 99% of time.
>>
>>109596339
>You can also drop any variable at any place using drop() function.
nope, drop() only works on heap allocated types that implement the drop trait
>>
>>109596358
wrong
drop("dumb retard");
>>
>>109596339
>scope doesn't really matter much
it does matter for variables, even the ones that hold references go out of scope only at the end brace, look at this >>109594486, r still remains in scope after the borrow ends, what we gained with NLL is that lifetime of a borrows is no longer tied to the lexical scope of the variables it are bound to.
>>
>>109596399
>variables
see >>109594827
variables don't exist!!!!
except they do, see >>109594840
ACKKKKK!!!!!!!!!!!!1
>>
>>109596369
he is wrong. but you picked a no-op example lol, even if the &str was neither 'static nor literal, non-mut references are Copy, and thus, Drop does nothing on them.
>>
>>109596415
std::mem::drop is a noop function, not matter the type, dumb retard!
https://doc.rust-lang.org/stable/src/core/mem/mod.rs.html#1000-1002
>>
>>109596369
It does nothing to it dumb retard, infact a fucking gay ass copy is passed to it, as an argument, values stored on stock only get destroyed when the stack frame itself is flushed out, values that implement Copy do not fucking move, so there is no ownership involved at all.
>>
>>109596429
moving is not a no-op retard. with Copy values, no moving happens, and that's why it becomes a no-op. this is rust 101.
>>
>>109596439
dumb retard, read >>109596358 again
dumb retard!
>>
>>109596415
this, that dumb retard is clueless
>>
>>109596444
>moving
I never said that. read >>109596358 again, dumb retard!

>>109596450
dumb retard
>>
>>109596358
You are confused the meaning of Drop, Copy and heap.
drop works on any value. It's just doesn't do anything for Copy values because they can't be Drop and they get memcpy'd on useanyway. But you can still drop Copy values like >>109596369 shown. However you also do not need heap for drop to be useful. For example:
use core::cell::RefCell;

fn main() {
let cell = RefCell::new(123);
let borrow = cell.borrow();

drop(borrow); // You need this or program will panic

*cell.borrow_mut() += 1;

println!("{}", cell.borrow());
}

Note that I am using core library, there is no heap used here at all. Yet borrow holds a runtime borrow on a cell. You need to manually drop it in order for RefCell to not panic when you borrow_mut it.
>>
>>109596447
yeah that is true, drop() doesn't work on values that implement Copy, fuck off retarded nigger
>>
>>109596457
wow, someone who isn't a dumb retard in a dumb retard thread, amazing!
>>
>>109596461
see >>109596457
dumb retard!
>>
>>109596399
i hope you're pretending to be retarded (or in your mind "baiting").
let bindings have a lexical scope. lifeness is not necessarily lexical. the value stayed in scope because you literally used it again. it's not that complex.
>>
>>109596399
>look at this >>109594486, r still remains in scope after the borrow ends
Yeah, it remains in scope as long as it can. Am I just saying that you do not have to worry about it as a normal developer. Unless you are using RefCells or similar and need to be mindful of manual drops, the compiler will just adjust the lifetime of objects as needed or report to you what's wrong and why.
>>
>>109596457
My point is that calling drop on Copy values is redundant, it doesn't do anything to them.
>>
>>109596455
>izzat tard who doesn't know the basics
>>
>>109596467
Can you read nigger? Or are you faggot bot larper?
>>
>>109596471
>calling drop on Copy values is redundant
That is true and obvious. But:
>drop() only works on heap allocated types
Is just plain wrong in many ways.
>>
>>109596470
>remains in scope as long as it can
it (variable) remains in scope until the block where it was declared ends (lexical scope), this is why you must READ and understand the whole concept.
With NLL, lifetime of a reference is no longer tied to the lexical of scope of the variable it is bound to.
>>
>>109596490
by "works" I mean, does its intended job.
>>
>>109596524
It doesn't need the heap to "do it's intended job". It can also release runtime borrows with no heap whatsoever like in >>109596457 code
>>
>>109596524
ohhhh i think i know where your retarded confusion comes from. you thing mem::drop() is akin to free() lol.
that's like the runtime guy tard who thought portable meant self-contained windows programs you can have on a flash stick.
>>
>>109596519
>it (variable) remains in scope until the block where it was declared ends (lexical scope),
Not always. It can also be moved out of scope. It could also be conditionally moved out of scope and then you get a hidden drop flag added to the stack.
>>
>>109596578
First of all I don't think you fully understand what "move" means and secondly "BY DEFAULT" scope of a variable ends at the closing brace of the block it is declared in.
>>109596549
std::mem::drop(x) is just an empty function that takes ownership of x's value, so that x goes out of scope (this is called a move), this triggers Drop::drop(), the Drop trait method, which then cleans up that value's memory.
In case you pass a local stack stored variable to it, literally nothing happens, the whole thing is redundant cuz that variable never goes of scope (you passed a copy).
>>
>>109597006
>First of all I don't think you fully understand what "move" means
It is very likely that I was programming in Rust before you ever heard of that language and know what a move is way better than you do.
If you disagree and think I am wrong then you gotta prove it. So far you have failed to provide any actual counterargument to anything I have said so far.
>>
>>109597006
>In case you pass a local stack stored variable to it, literally nothing happens
This is wrong. See >>109596457 for example.
>>
>>109597006
even if you implement Drop for stack stored data, nothing happens *today*. but nothing prevents future rust from reusing non-life stack data in the future, with code generator support/cooperation of course.
again, this is the exact educational abstraction leakage i complained about.
>>
>>109597420
*empty Drop i should have said.
>>
File: frog.jpg (54 KB, 976x850)
54 KB JPG
These are not Rust concepts.
>>
>>109597420
>nothing prevents future rust from reusing non-life stack data in the future
It already does this (in certain situations) when using optimized builds.
>>
>>109597485
a lot of shit can happen in optimized builds.
but let's keep things simple for the "C is portable ASM" meme crowd.
>>
>>109594216
Just use ada
>>
>>109597919
No libraries
>>
>>109597445
which other languages implement these concepts then?
>>
>>109598220
>the first 3
Nearly every programming language in existence (C, java, etc.)
>the last 1
Garbage collected languages



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.