131–140 of 342 posts
When I read these articles everything always seems so understandable, but I can pretty much guarantee that I won’t remember much tomorrow.
Same with me, to learn anything I need to write it down, possibly several times.
Earlier quoted context omitted.
What confuses me is... why do you think the meaning is different? There is no meaning overload. It's a single meaning. T: 'static would happily typecheck with &'a str if 'a: 'static. T: 'static typechecks: - OwnedValue - OwnedValueWithReferences where 'a: 'static - &'a ReferencedValue where 'a: 'static /// &'static ReferencedValue - Foo where 'a: 'static /// Foo ...and more. See the example here: https://play.rust-la…
What you say makes sense... but I struggle to reconcile it with reality. If "the left part of this bound can live up to the end of the application" then why is &a not 'a where 'a: 'static? a can live up to the end of the application. &a can live up to the end of the application. Why is the result "argument requires that `a` is borrowed for `'static`" fn foo (a: &'a str) { println!("{}", a) } pub fn main() { let a = "…
If you do 'a: 'static, then you just said 'a is at least as long as 'static.
When you borrow the String, you just created a lifetime that is not as long as 'static. Variables are dropped (and hence unborrowed) in reverse order. So 'a will necessarily be dropped before its owner, hence it's shorter than 'static.
As you can see it complains that it's dropped at the end of main() even though it should be borrowed for 'static. If this was an owned value it would NOT be dropped at main() since it would be moved into the function on call.
Nothing surprising here.
> &a can live up to the end of the application
Nope. Imagine spawning a thread and passing &a but keeping 'a' in your main thread.
> bow out of this conversation thread I'm afraid
Welp I did what I could.
Earlier quoted context omitted.
That will work fine, because 2 is 'Copy', so it can be copied trivially (as are structs consisting only of Copy members which are marked as Copy). Roughly speaking anything with a pointer in it isn't Copy, though many objects will implement Clone, which basically just means you need to explicitly call .clone() to make a copy instead of it happening implicitly.
2 is Copy? It's an integer, could be 2.0 if you wanted to make it a float. Someone needs to explicitly nail down the mission statement of Rust... because to me it seems to be "Rust will introduce pointers where they don't need to be, and then try to protect you from the results with obsessive rules"
Maybe playing around with the code would help you better, because that last line doesn't make any sense: https://play.rust-lang.org/?version=stable&mode=debug&editio...
There wasn't anything on concurrency or asynchronous programming (like a http client). Is there a good resource for those parts of the language?
I might write another one that focuses on the happy path.
(Side note: dear Apple, please add syntax coloring and code formatting for Rust to Xcode. You have Fortran and C Shell in the list, but not Rust or Go, which are much more popular!)
Is there any reason to use Xcode for Rust development?
There's a lot of valuable, condensed knowledge here, but for those who wish to learn the language in a more interactive way I recommend Rustlings: https://github.com/rust-lang/rustlings I spent the last two weeks going through it and so far the experience has been great. There's a quiz at the end of most chapters.
Earlier quoted context omitted.
You keep using this word, variables. I don't think it means what you think it means. At least in my book pointers are still variables (as in "a pointer variable"), and a variable is any named value, whether it's a scalar or a pointer or a nth-pointer, or what its storage is. But you mean that in your example there is no way to affect the previous value, right? > I just googled it... why the heck would you copy pointe…
Variables can be varied... you can increment, decrement, do whatever you want with them. They keep track of things. Pointers are used reference things allocated from the heap, and never anything else, unless you're insane. Pointers get directly handled in linked lists, trees, etc. If at all possible, pointers should be avoided otherwise. Values passed to a procedure can be done by value (the default in Pascal), or by…
People routinely use pointers to things on the stack in several languages. Rust even makes it safe to do that, using lifetimes - a pointer to something on the stack can't outlive the stack frame it points into.
> I don't see why anyone wouldn't copy values by default...
Because not everything is safe to copy. In particular, Rust has a few kinds of pointers which come with special rules.
Firstly, it has boxes, which always point to something on the heap, and have a rule that that when the pointer dies, the thing it points to gets freed. If you copied a box, then when one of the copies died, the thing would be freed, and then the other copy would have a pointer to invalid memory, which would be bad.
Secondly, it has mutable references, which come with a guarantee that a mutable reference is the only pointer to a given thing. If you copied a mutable reference, you would break that guarantee.
Thirdly, it has reference-counting pointers (these are in the standard library, not the language). You can make duplicates of those, but they have to increment their reference count when you do so. Copying is always just a bitwise copy, so there is no chance to increment the reference count. Instead, duplication is an explicit operation.
There are a few other things it doesn't make sense to copy. Like, what would it mean to copy a mutex?
So, in Rust, you can't copy by default. However, it is really easy to mark a type as being copyable (the compiler will check that it really is, ie doesn't contain any non-copyable things), and then you can copy it.
Earlier quoted context omitted.
You keep using this word, variables. I don't think it means what you think it means. At least in my book pointers are still variables (as in "a pointer variable"), and a variable is any named value, whether it's a scalar or a pointer or a nth-pointer, or what its storage is. But you mean that in your example there is no way to affect the previous value, right? > I just googled it... why the heck would you copy pointe…
Variables can be varied... you can increment, decrement, do whatever you want with them. They keep track of things. Pointers are used reference things allocated from the heap, and never anything else, unless you're insane. Pointers get directly handled in linked lists, trees, etc. If at all possible, pointers should be avoided otherwise. Values passed to a procedure can be done by value (the default in Pascal), or by…
You can do the same to a pointer in languages that have them, either directly (e.g. in C) or through some "unsafe" construct (e.g. in Rust, C#, Go).
>I don't see why anyone wouldn't copy values by default... it is the only sane way to do things.
When resources are ample, yes. Not the case historically, or in many use cases today.
And not all values make sense to copy.
But also in Rust, we're talking in the context of C performance needs, memory models, and concepts, and Rust expands and makes those safe.