Rust  Language

Rust Language

1575896148

The Rust Programming Language - Understanding Lifetimes in Rust

This is one of Rust’s most distinct and compelling features, with which Rust developers should become quite acquainted. Ownership is how Rust achieves its largest goal, memory safety. There are a few distinct concepts, each with its own chapter:

  • ownership, the key concept
  • borrowing, and their associated feature ‘references’
  • lifetimes, which you’re reading now

These three chapters are related, and in order. You’ll need all three to fully understand the ownership system.

Meta

Before we get to the details, two important notes about the ownership system.

Rust has a focus on safety and speed. It accomplishes these goals through many ‘zero-cost abstractions’, which means that in Rust, abstractions cost as little as possible in order to make them work. The ownership system is a prime example of a zero-cost abstraction. All of the analysis we’ll talk about in this guide is done at compile time. You do not pay any run-time cost for any of these features.

However, this system does have a certain cost: learning curve. Many new users to Rust experience something we like to call ‘fighting with the borrow checker’, where the Rust compiler refuses to compile a program that the author thinks is valid. This often happens because the programmer’s mental model of how ownership should work doesn’t match the actual rules that Rust implements. You probably will experience similar things at first. There is good news, however: more experienced Rust developers report that once they work with the rules of the ownership system for a period of time, they fight the borrow checker less and less.

With that in mind, let’s learn about lifetimes.

Lifetimes

Lending out a reference to a resource that someone else owns can be complicated. For example, imagine this set of operations:

  1. I acquire a handle to some kind of resource.
  2. I lend you a reference to the resource.
  3. I decide I’m done with the resource, and deallocate it, while you still have your reference.
  4. You decide to use the resource.

Uh oh! Your reference is pointing to an invalid resource. This is called a dangling pointer or ‘use after free’, when the resource is memory. A small example of such a situation would be:

let r;              // Introduce reference: `r`.
{
    let i = 1;      // Introduce scoped value: `i`.
    r = &i;         // Store reference of `i` in `r`.
}                   // `i` goes out of scope and is dropped.

println!("{}", r);  // `r` still refers to `i`.

To fix this, we have to make sure that step four never happens after step three. In the small example above the Rust compiler is able to report the issue as it can see the lifetimes of the various values in the function.

When we have a function that takes arguments by reference the situation becomes more complex. Consider the following example:

fn skip_prefix(line: &str, prefix: &str) -> &str {
    // ...
#   line
}

let line = "lang:en=Hello World!";
let lang = "en";

let v;
{
    let p = format!("lang:{}=", lang);  // -+ `p` comes into scope.
    v = skip_prefix(line, p.as_str());  //  |
}                                       // -+ `p` goes out of scope.
println!("{}", v);

Here we have a function skip_prefix which takes two &str references as parameters and returns a single &str reference. We call it by passing in references to line and p: Two variables with different lifetimes. Now the safety of the println!-line depends on whether the reference returned by skip_prefix function references the still living line or the already dropped p string.

Because of the above ambiguity, Rust will refuse to compile the example code. To get it to compile we need to tell the compiler more about the lifetimes of the references. This can be done by making the lifetimes explicit in the function declaration:


# #![allow(unused_variables)]
#fn main() {
fn skip_prefix<'a, 'b>(line: &'a str, prefix: &'b str) -> &'a str {
    // ...
#   line
}
#}

Let’s examine the changes without going too deep into the syntax for now - we’ll get to that later. The first change was adding the <'a, 'b> after the method name. This introduces two lifetime parameters: 'a and 'b. Next, each reference in the function signature was associated with one of the lifetime parameters by adding the lifetime name after the &. This tells the compiler how the lifetimes between different references are related.

As a result the compiler is now able to deduce that the return value of skip_prefix has the same lifetime as the line parameter, which makes the v reference safe to use even after the p goes out of scope in the original example.

In addition to the compiler being able to validate the usage of skip_prefix return value, it can also ensure that the implementation follows the contract established by the function declaration. This is useful especially when you are implementing traits that are introduced later in the book.

Note It’s important to understand that lifetime annotations are descriptive, not prescriptive. This means that how long a reference is valid is determined by the code, not by the annotations. The annotations, however, give information about lifetimes to the compiler that uses them to check the validity of references. The compiler can do so without annotations in simple cases, but needs the programmer’s support in complex scenarios.

Syntax

The 'a reads ‘the lifetime a’. Technically, every reference has some lifetime associated with it, but the compiler lets you elide (i.e. omit, see “Lifetime Elision” below) them in common cases. Before we get to that, though, let’s look at a short example with explicit lifetimes:

fn bar<'a>(...)

We previously talked a little about function syntax, but we didn’t discuss the <>s after a function’s name. A function can have ‘generic parameters’ between the <>s, of which lifetimes are one kind. We’ll discuss other kinds of generics later in the book, but for now, let’s focus on the lifetimes aspect.

We use <> to declare our lifetimes. This says that bar has one lifetime, 'a. If we had two reference parameters with different lifetimes, it would look like this:

fn bar<'a, 'b>(...)

Then in our parameter list, we use the lifetimes we’ve named:

...(x: &'a i32)

If we wanted a &mut reference, we’d do this:

...(x: &'a mut i32)

If you compare &mut i32 to &'a mut i32, they’re the same, it’s that the lifetime 'a has snuck in between the & and the mut i32. We read &mut i32 as ‘a mutable reference to an i32’ and &'a mut i32 as ‘a mutable reference to an i32 with the lifetime 'a’.

In structs

You’ll also need explicit lifetimes when working with structs that contain references:

struct Foo<'a> {
    x: &'a i32,
}

fn main() {
    let y = &5; // This is the same as `let _y = 5; let y = &_y;`.
    let f = Foo { x: y };

    println!("{}", f.x);
}

As you can see, structs can also have lifetimes. In a similar way to functions,


# #![allow(unused_variables)]
#fn main() {
struct Foo<'a> {
# x: &'a i32,
# }
#}

declares a lifetime, and


# #![allow(unused_variables)]
#fn main() {
# struct Foo<'a> {
x: &'a i32,
# }
#}

uses it. So why do we need a lifetime here? We need to ensure that any reference to a Foo cannot outlive the reference to an i32 it contains.

impl blocks

Let’s implement a method on Foo:

struct Foo<'a> {
    x: &'a i32,
}

impl<'a> Foo<'a> {
    fn x(&self) -> &'a i32 { self.x }
}

fn main() {
    let y = &5; // This is the same as `let _y = 5; let y = &_y;`.
    let f = Foo { x: y };

    println!("x is: {}", f.x());
}

As you can see, we need to declare a lifetime for Foo in the impl line. We repeat 'a twice, like on functions: impl<'a> defines a lifetime 'a, and Foo<'a> uses it.

Multiple lifetimes

If you have multiple references, you can use the same lifetime multiple times:


# #![allow(unused_variables)]
#fn main() {
fn x_or_y<'a>(x: &'a str, y: &'a str) -> &'a str {
#    x
# }
#}

This says that x and y both are alive for the same scope, and that the return value is also alive for that scope. If you wanted x and y to have different lifetimes, you can use multiple lifetime parameters:


# #![allow(unused_variables)]
#fn main() {
fn x_or_y<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
#    x
# }
#}

In this example, x and y have different valid scopes, but the return value has the same lifetime as x.

Thinking in scopes

A way to think about lifetimes is to visualize the scope that a reference is valid for. For example:

fn main() {
    let y = &5;     // -+ `y` comes into scope.
                    //  |
    // Stuff...     //  |
                    //  |
}                   // -+ `y` goes out of scope.

Adding in our Foo:

struct Foo<'a> {
    x: &'a i32,
}

fn main() {
    let y = &5;           // -+ `y` comes into scope.
    let f = Foo { x: y }; // -+ `f` comes into scope.
                          //  |
    // Stuff...           //  |
                          //  |
}                         // -+ `f` and `y` go out of scope.

Our f lives within the scope of y, so everything works. What if it didn’t? This code won’t work:

struct Foo<'a> {
    x: &'a i32,
}

fn main() {
    let x;                    // -+ `x` comes into scope.
                              //  |
    {                         //  |
        let y = &5;           // ---+ `y` comes into scope.
        let f = Foo { x: y }; // ---+ `f` comes into scope.
        x = &f.x;             //  | | This causes an error.
    }                         // ---+ `f` and y go out of scope.
                              //  |
    println!("{}", x);        //  |
}                             // -+ `x` goes out of scope.

Whew! As you can see here, the scopes of f and y are smaller than the scope of x. But when we do x = &f.x, we make x a reference to something that’s about to go out of scope.

Named lifetimes are a way of giving these scopes a name. Giving something a name is the first step towards being able to talk about it.

'static

The lifetime named ‘static’ is a special lifetime. It signals that something has the lifetime of the entire program. Most Rust programmers first come across 'static when dealing with strings:


# #![allow(unused_variables)]
#fn main() {
let x: &'static str = "Hello, world.";
#}

String literals have the type &'static str because the reference is always alive: they are baked into the data segment of the final binary. Another example are globals:


# #![allow(unused_variables)]
#fn main() {
static FOO: i32 = 5;
let x: &'static i32 = &FOO;
#}

This adds an i32 to the data segment of the binary, and x is a reference to it.

Lifetime Elision

Rust supports powerful local type inference in the bodies of functions, but it deliberately does not perform any reasoning about types for item signatures. However, for ergonomic reasons, a very restricted secondary inference algorithm called “lifetime elision” does apply when judging lifetimes. Lifetime elision is concerned solely with inferring lifetime parameters using three easily memorizable and unambiguous rules. This means lifetime elision acts as a shorthand for writing an item signature, while not hiding away the actual types involved as full local inference would if applied to it.

When talking about lifetime elision, we use the terms input lifetime and output lifetime. An input lifetime is a lifetime associated with a parameter of a function, and an output lifetime is a lifetime associated with the return value of a function. For example, this function has an input lifetime:

fn foo<'a>(bar: &'a str)

This one has an output lifetime:

fn foo<'a>() -> &'a str

This one has a lifetime in both positions:

fn foo<'a>(bar: &'a str) -> &'a str

Here are the three rules:

  • Each elided lifetime in a function’s arguments becomes a distinct lifetime parameter.

  • If there is exactly one input lifetime, elided or not, that lifetime is assigned to all elided lifetimes in the return values of that function.

  • If there are multiple input lifetimes, but one of them is &self or &mut self, the lifetime of self is assigned to all elided output lifetimes.

Otherwise, it is an error to elide an output lifetime.

Examples

Here are some examples of functions with elided lifetimes. We’ve paired each example of an elided lifetime with its expanded form.

fn print(s: &str); // elided
fn print<'a>(s: &'a str); // expanded

fn debug(lvl: u32, s: &str); // elided
fn debug<'a>(lvl: u32, s: &'a str); // expanded

In the preceding example, lvl doesn’t need a lifetime because it’s not a reference (&). Only things relating to references (such as a struct which contains a reference) need lifetimes.

fn substr(s: &str, until: u32) -> &str; // elided
fn substr<'a>(s: &'a str, until: u32) -> &'a str; // expanded

fn get_str() -> &str; // ILLEGAL, no inputs

fn frob(s: &str, t: &str) -> &str; // ILLEGAL, two inputs
fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // Expanded: Output lifetime is ambiguous

fn get_mut(&mut self) -> &mut T; // elided
fn get_mut<'a>(&'a mut self) -> &'a mut T; // expanded

fn args<T: ToCStr>(&mut self, args: &[T]) -> &mut Command; // elided
fn args<'a, 'b, T: ToCStr>(&'a mut self, args: &'b [T]) -> &'a mut Command; // expanded

fn new(buf: &mut [u8]) -> BufWriter; // elided
fn new<'a>(buf: &'a mut [u8]) -> BufWriter<'a>; // expanded

#Rust #WebDev

What is GEEK

Buddha Community

The Rust Programming Language - Understanding Lifetimes in Rust

RUST on programming language

The title is a bit confusing to understand the context of the content. In this blog, I am going to run around and see the different aspects of programming language rust. And talk about the concepts that it introduces that are useful for various aspects of programming.

What is Rust?

Simply putting it is a statically as well as strongly typed programming language.

Let me explain:

_statically typed _indicates that all the datatypes that are expressed in the code are known at compile time and memory allocation is done properly.

Image for post

Then what is 👆 that? Let’s just say rust knows what you want to say.

But this doesn’t mean you could declare variables for a complex data type and expect rust to understand. Here comes the next point I mentioned above.

_strongly typed _indicates that the types are designed to make it harder to write syntatically incorrect code.

If you were to do even a little mistake with the syntax or definition of variables then the errors are caught at compile time. Not just the syntax errors but there are various tests build in the compiler to check for unused variablesdead code(Code that will never run), infinite loops as well as the lifetime of variables.

#security #programming #programming-languages #rust

Cayla  Erdman

Cayla Erdman

1594369800

Introduction to Structured Query Language SQL pdf

SQL stands for Structured Query Language. SQL is a scripting language expected to store, control, and inquiry information put away in social databases. The main manifestation of SQL showed up in 1974, when a gathering in IBM built up the principal model of a social database. The primary business social database was discharged by Relational Software later turning out to be Oracle.

Models for SQL exist. In any case, the SQL that can be utilized on every last one of the major RDBMS today is in various flavors. This is because of two reasons:

1. The SQL order standard is genuinely intricate, and it isn’t handy to actualize the whole standard.

2. Every database seller needs an approach to separate its item from others.

Right now, contrasts are noted where fitting.

#programming books #beginning sql pdf #commands sql #download free sql full book pdf #introduction to sql pdf #introduction to sql ppt #introduction to sql #practical sql pdf #sql commands pdf with examples free download #sql commands #sql free bool download #sql guide #sql language #sql pdf #sql ppt #sql programming language #sql tutorial for beginners #sql tutorial pdf #sql #structured query language pdf #structured query language ppt #structured query language

Biju Augustian

Biju Augustian

1574340419

Guide to Python Programming Language

Description
The course will lead you from beginning level to advance in Python Programming Language. You do not need any prior knowledge on Python or any programming language or even programming to join the course and become an expert on the topic.

The course is begin continuously developing by adding lectures regularly.

Please see the Promo and free sample video to get to know more.

Hope you will enjoy it.

Basic knowledge
An Enthusiast Mind
A Computer
Basic Knowledge To Use Computer
Internet Connection
What will you learn
Will Be Expert On Python Programming Language
Build Application On Python Programming Language

#uide to Python #Guide to Python Programming #Guide to Python Programming Language #Python Programming #Python Programming Language

Alayna  Rippin

Alayna Rippin

1600898400

OS in Rust: An executable that runs on bare metal

This is the very first blog of the series that pertains to create a basic Operating System using Rust Programming Language.

The aim of this series is to learn and understand the basics of Operating System. Through this series, you will get some ideas about the internal components of Operating System and how they interact with each other.

In this article, we will create a freestanding binary (an executable) that has the capability to run on bare metal. To create that executable we need to follow certain steps:

Steps to create a bare-metal executable:

  • Disable standard library
  • Define custom panic handler
  • Provide language items
  • Provide entry point
  • Build executable

#functional programming #rust #rust programming language #system programming

Iliana  Welch

Iliana Welch

1590893280

This Rust programming language

This Rust programming language tutorial series is aimed at easing your training step by step. Rust is a systems level language aimed at speed and safety and can be run cross-platform, including embedded systems and even the browser with WebAssembly (WASM)! I use the VS Code development environment to help you learn the core topics. Please join me on this journey with this fantastic new programming language.

Subscribe to the channel https://www.youtube.com/watch?v=afFehipXJFA

#rust #programming #language