I assume it's derived from the OCaml generic type syntax (the first Rust compiler was written in OCaml after all), for example the definition of the type `Option.t` in OCaml:
type 'a t = 'a option =
| None
| Some of 'a
I think this is the case because IIRC this function:
fn slice<'a>(s: &'a str) -> &'a str { &s[0..2] }
Is generic over the lifetime of `s`, and it I assume it would have been difficult to distinguish generic types and lifetimes.
Personally, I've given up on Gemini, as it seems to have been censored to the point of uselessness. I asked it yesterday [0] about C++ 20 Concepts, and it refused to give actual code because I'm under 18 (I'm 17, and AFAIK that's what the age on my Google account is set to). I just checked again, and it gave a similar answer [1]. When I tried ChatGPT 3.5, it did give an answer, although it was a little confused, and the code wasn't completely correct.
This seems to be a common experience, as apparently it refuses to give advice on copying memory in C# [2], and I tried to do what was suggested in this comment [3], but by the next prompt it was refusing again, so I had to stick to ChatGPT.
I'm with Gemini on this one, 17 years old is too young to be learning about unsafe C++ features, best stick with a memory safe language until you're old enough
I've gotten similar pushback. I asked for a solution involving curl and was told that that was not something Gemini could do. Then I clicked the button to see the other drafts of Gemini's responses and got two versions that worked.
Well that was easy [0]. The second draft also revealed something about the prompt [1]. It seems that the more verbose the prompt is, the less it wants to reveal [2] [3]. Unfortunately I don’t seem to be able to get it to reveal anything more, and it refuses to cooperate with me when I try the ‘Developer Mode’ prompt which used to work on ChatGPT [4].
You're mostly correct, it is moved into the function (pass by value), and then, at the end of the function's scope, the destructor is called automatically (as the compiler inserts a call to `drop()` at the end of the function) which de-allocates the vec, causing the reference obtained in `main()` become a dangling pointer.
An alternative, more correct but less interesting, explanation: you really need to look at the disassembly (with your specific build of the Rust compiler with the same flags) to see what's really happening. This is why UB (undefined behavior) is dangerous.
For example, the compiler could decide that the entire allocation is unnecessary and elide it, if it's known that the Vec is very small. The compiler could also decide to pass it by ref. Remember that the compiler merely has to preserve your intent, beyond that it is allowed to do whatever it pleases.
As a fellow (very nearly) 17 year old, good job! :^) Just 20 minutes ago I was trying to figure out how to extract the first byte of a 16 bit integer and finding out about Endianness, and you're writing a whole book about CPUs! I'll make sure to read this once I've finished Crafting Interpreters, although it may take a while since progress with that has certainly slowed down (as it does with many of my other projects lol).
reply