1575550832
The Rust Programming Language - Understanding Variable Bindings in Rust
Virtually every non-'Hello World’ Rust program uses variable bindings. They bind some value to a name, so it can be used later. let is used to introduce a binding, like this:
fn main() {
let x = 5;
}
Putting fn main() { in each example is a bit tedious, so we’ll leave that out in the future. If you’re following along, make sure to edit your main() function, rather than leaving it off. Otherwise, you’ll get an error.
Patterns
In many languages, a variable binding would be called a variable, but Rust’s variable bindings have a few tricks up their sleeves. For example the left-hand side of a let statement is a ‘pattern’, not a variable name. This means we can do things like:
# #![allow(unused_variables)]
#fn main() {
let (x, y) = (1, 2);
#}
After this statement is evaluated, x will be one, and y will be two. Patterns are really powerful, and have their own section in the book. We don’t need those features for now, so we’ll keep this in the back of our minds as we go forward.
Type annotations
Rust is a statically typed language, which means that we specify our types up front, and they’re checked at compile time. So why does our first example compile? Well, Rust has this thing called ‘type inference’. If it can figure out what the type of something is, Rust doesn’t require you to explicitly type it out.
We can add the type if we want to, though. Types come after a colon (:):
# #![allow(unused_variables)]
#fn main() {
let x: i32 = 5;
#}
If I asked you to read this out loud to the rest of the class, you’d say “x is a binding with the type i32 and the value 5.”
In this case we chose to represent x as a 32-bit signed integer. Rust has many different primitive integer types. They begin with i for signed integers and u for unsigned integers. The possible integer sizes are 8, 16, 32, and 64 bits.
In future examples, we may annotate the type in a comment. The examples will look like this:
fn main() {
let x = 5; // x: i32
}
Note the similarities between this annotation and the syntax you use with let. Including these kinds of comments is not idiomatic Rust, but we’ll occasionally include them to help you understand what the types that Rust infers are.
Mutability
By default, bindings are immutable. This code will not compile:
let x = 5;
x = 10;
It will give you this error:
error: re-assignment of immutable variable `x`
x = 10;
^~~~~~~
If you want a binding to be mutable, you can use mut:
# #![allow(unused_variables)]
#fn main() {
let mut x = 5; // mut x: i32
x = 10;
#}
There is no single reason that bindings are immutable by default, but we can think about it through one of Rust’s primary focuses: safety. If you forget to say mut, the compiler will catch it, and let you know that you have mutated something you may not have intended to mutate. If bindings were mutable by default, the compiler would not be able to tell you this. If you did intend mutation, then the solution is quite easy: add mut.
There are other good reasons to avoid mutable state when possible, but they’re out of the scope of this guide. In general, you can often avoid explicit mutation, and so it is preferable in Rust. That said, sometimes, mutation is what you need, so it’s not forbidden.
Initializing bindings
Rust variable bindings have one more aspect that differs from other languages: bindings are required to be initialized with a value before you’re allowed to use them.
Let’s try it out. Change your src/main.rs file to look like this:
fn main() {
let x: i32;
println!("Hello world!");
}
You can use cargo build on the command line to build it. You’ll get a warning, but it will still print “Hello, world!”:
Compiling hello_world v0.0.1 (file:///home/you/projects/hello_world)
src/main.rs:2:9: 2:10 warning: unused variable: `x`, #[warn(unused_variables)]
on by default
src/main.rs:2 let x: i32;
^
Rust warns us that we never use the variable binding, but since we never use it, no harm, no foul. Things change if we try to actually use this x, however. Let’s do that. Change your program to look like this:
fn main() {
let x: i32;
println!("The value of x is: {}", x);
}
And try to build it. You’ll get an error:
$ cargo build
Compiling hello_world v0.0.1 (file:///home/you/projects/hello_world)
src/main.rs:4:39: 4:40 error: use of possibly uninitialized variable: `x`
src/main.rs:4 println!("The value of x is: {}", x);
^
note: in expansion of format_args!
<std macros>:2:23: 2:77 note: expansion site
<std macros>:1:1: 3:2 note: in expansion of println!
src/main.rs:4:5: 4:42 note: expansion site
error: aborting due to previous error
Could not compile `hello_world`.
Rust will not let us use a value that has not been initialized.
Let us take a minute to talk about this stuff we’ve added to println!.
If you include two curly braces ({}, some call them moustaches…) in your string to print, Rust will interpret this as a request to interpolate some sort of value. String interpolation is a computer science term that means “stick in the middle of a string.” We add a comma, and then x, to indicate that we want x to be the value we’re interpolating. The comma is used to separate arguments we pass to functions and macros, if you’re passing more than one.
When you use the curly braces, Rust will attempt to display the value in a meaningful way by checking out its type. If you want to specify the format in a more detailed manner, there are a wide number of options available. For now, we’ll stick to the default: integers aren’t very complicated to print.
Scope and shadowing
Let’s get back to bindings. Variable bindings have a scope - they are constrained to live in the block they were defined in. A block is a collection of statements enclosed by { and }. Function definitions are also blocks! In the following example we define two variable bindings, x and y, which live in different blocks. x can be accessed from inside the fn main() {} block, while y can be accessed only from inside the inner block:
fn main() {
let x: i32 = 17;
{
let y: i32 = 3;
println!("The value of x is {} and value of y is {}", x, y);
}
println!("The value of x is {} and value of y is {}", x, y); // This won't work.
}
The first println! would print “The value of x is 17 and the value of y is 3”, but this example cannot be compiled successfully, because the second println! cannot access the value of y, since it is not in scope anymore. Instead we get this error:
$ cargo build
Compiling hello v0.1.0 (file:///home/you/projects/hello_world)
main.rs:7:62: 7:63 error: unresolved name `y`. Did you mean `x`? [E0425]
main.rs:7 println!("The value of x is {} and value of y is {}", x, y); // This won't work.
^
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!
main.rs:7:5: 7:65 note: expansion site
main.rs:7:62: 7:63 help: run `rustc --explain E0425` to see a detailed explanation
error: aborting due to previous error
Could not compile `hello`.
To learn more, run the command again with --verbose.
Additionally, variable bindings can be shadowed. This means that a later variable binding with the same name as another binding that is currently in scope will override the previous binding.
# #![allow(unused_variables)]
#fn main() {
let x: i32 = 8;
{
println!("{}", x); // Prints "8".
let x = 12;
println!("{}", x); // Prints "12".
}
println!("{}", x); // Prints "8".
let x = 42;
println!("{}", x); // Prints "42".
#}
Shadowing and mutable bindings may appear as two sides of the same coin, but they are two distinct concepts that can’t always be used interchangeably. For one, shadowing enables us to rebind a name to a value of a different type. It is also possible to change the mutability of a binding. Note that shadowing a name does not alter or destroy the value it was bound to, and the value will continue to exist until it goes out of scope, even if it is no longer accessible by any means.
# #![allow(unused_variables)]
#fn main() {
let mut x: i32 = 1;
x = 7;
let x = x; // `x` is now immutable and is bound to `7`.
let y = 4;
let y = "I can also be bound to text!"; // `y` is now of a different type.
#}
#rust #webdev
What is GEEK
Buddha Community
1596826740
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.
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 variables, dead code(Code that will never run), infinite loops as well as the lifetime of variables.
#security #programming #programming-languages #rust
1643176207
Serde Rust: Serialization Framework for Rust
Serde
*Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.*
You may be looking for:
- An overview of Serde
- Data formats supported by Serde
- Setting up
#[derive(Serialize, Deserialize)] - Examples
- API documentation
- Release notes
Serde in action
Click to show Cargo.toml. Run this code in the playground.
[dependencies]
# The core APIs, including the Serialize and Deserialize traits. Always
# required when using Serde. The "derive" feature is only required when
# using #[derive(Serialize, Deserialize)] to make Serde work with structs
# and enums defined in your crate.
serde = { version = "1.0", features = ["derive"] }
# Each data format lives in its own crate; the sample code below uses JSON
# but you may be using a different one.
serde_json = "1.0"
use serde::{Serialize, Deserialize};
#[derive(Serialize, Deserialize, Debug)]
struct Point {
x: i32,
y: i32,
}
fn main() {
let point = Point { x: 1, y: 2 };
// Convert the Point to a JSON string.
let serialized = serde_json::to_string(&point).unwrap();
// Prints serialized = {"x":1,"y":2}
println!("serialized = {}", serialized);
// Convert the JSON string back to a Point.
let deserialized: Point = serde_json::from_str(&serialized).unwrap();
// Prints deserialized = Point { x: 1, y: 2 }
println!("deserialized = {:?}", deserialized);
}
Getting help
Serde is one of the most widely used Rust libraries so any place that Rustaceans congregate will be able to help you out. For chat, consider trying the #rust-questions or #rust-beginners channels of the unofficial community Discord (invite: https://discord.gg/rust-lang-community), the #rust-usage or #beginners channels of the official Rust Project Discord (invite: https://discord.gg/rust-lang), or the #general stream in Zulip. For asynchronous, consider the [rust] tag on StackOverflow, the /r/rust subreddit which has a pinned weekly easy questions post, or the Rust Discourse forum. It's acceptable to file a support issue in this repo but they tend not to get as many eyes as any of the above and may get closed without a response after some time.
Download Details:
Author: serde-rs
Source Code: https://github.com/serde-rs/serde
License: View license
1636172239
Variable Bindings in Rust - The Rust Programming Language
Variable Bindings
Rust provides type safety via static typing. Variable bindings can be type annotated when declared. However, in most cases, the compiler will be able to infer the type of the variable from the context, heavily reducing the annotation burden.
Values (like literals) can be bound to variables, using the let binding.
fn main() {
let an_integer = 1u32;
let a_boolean = true;
let unit = ();
// copy `an_integer` into `copied_integer`
let copied_integer = an_integer;
println!("An integer: {:?}", copied_integer);
println!("A boolean: {:?}", a_boolean);
println!("Meet the unit value: {:?}", unit);
// The compiler warns about unused variable bindings; these warnings can
// be silenced by prefixing the variable name with an underscore
let _unused_variable = 3u32;
let noisy_unused_variable = 2u32;
// FIXME ^ Prefix with an underscore to suppress the warning
}Mutability
Variable bindings are immutable by default, but this can be overridden using the mut modifier.
fn main() {
let _immutable_binding = 1;
let mut mutable_binding = 1;
println!("Before mutation: {}", mutable_binding);
// Ok
mutable_binding += 1;
println!("After mutation: {}", mutable_binding);
// Error!
_immutable_binding += 1;
// FIXME ^ Comment out this line
}
The compiler will throw a detailed diagnostic about mutability errors.
Scope and Shadowing
Variable bindings have a scope, and are constrained to live in a block. A block is a collection of statements enclosed by braces {}.
fn main() {
// This binding lives in the main function
let long_lived_binding = 1;
// This is a block, and has a smaller scope than the main function
{
// This binding only exists in this block
let short_lived_binding = 2;
println!("inner short: {}", short_lived_binding);
}
// End of the block
// Error! `short_lived_binding` doesn't exist in this scope
println!("outer short: {}", short_lived_binding);
// FIXME ^ Comment out this line
println!("outer long: {}", long_lived_binding);
}
Also, variable shadowing is allowed.
fn main() {
let shadowed_binding = 1;
{
println!("before being shadowed: {}", shadowed_binding);
// This binding *shadows* the outer one
let shadowed_binding = "abc";
println!("shadowed in inner block: {}", shadowed_binding);
}
println!("outside inner block: {}", shadowed_binding);
// This binding *shadows* the previous binding
let shadowed_binding = 2;
println!("shadowed in outer block: {}", shadowed_binding);
}
Declare first
It's possible to declare variable bindings first, and initialize them later. However, this form is seldom used, as it may lead to the use of uninitialized variables.
fn main() {
// Declare a variable binding
let a_binding;
{
let x = 2;
// Initialize the binding
a_binding = x * x;
}
println!("a binding: {}", a_binding);
let another_binding;
// Error! Use of uninitialized binding
println!("another binding: {}", another_binding);
// FIXME ^ Comment out this line
another_binding = 1;
println!("another binding: {}", another_binding);
}
The compiler forbids use of uninitialized variables, as this would lead to undefined behavior.
Freezing
When data is bound by the same name immutably, it also freezes. Frozen data can't be modified until the immutable binding goes out of scope:
fn main() {
let mut _mutable_integer = 7i32;
{
// Shadowing by immutable `_mutable_integer`
let _mutable_integer = _mutable_integer;
// Error! `_mutable_integer` is frozen in this scope
_mutable_integer = 50;
// FIXME ^ Comment out this line
// `_mutable_integer` goes out of scope
}
// Ok! `_mutable_integer` is not frozen in this scope
_mutable_integer = 3;
}
#rust #programming #developer
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
1598590980
Variable Shadowing: "Let" Keyword Is Immutable But Not Constant Variable
Let’s take a look at some of the common pitfalls with the keywords let and mut**. **Then, we will learn how **immutable != constant **by using_ variable shadowing_.
Getting started with Rust can be daunting. Rust is well-known for being a safe language. One of the ways in which Rust is safe is through type-safety. Rust is strongly typed and defaults to immutable values.
The “let” Keyword
The simplest way to create a new variable in Rust is by using the “let” keyword:
fn main() {
let my_num = 5;
println!("{}", my_num);
}
let introduces a new variable into the current scope. By default new variables are immutable, which means they can’t be reassigned. For example:
fn main() {
let my_num = 5;
my_num = 6;
println!("{}", my_num);
}
fails to compile with the error: cannot assign twice to immutable variable
In Rust the keyword “let” in Rust can confused devs coming from JavaScript. In JS “let” is used to declare mutable values. In Rust, “let” declares immutable values, which contributes to Rust being a safer language. #rustlang #rust
#rust #rustlang #immutable #constant #programming #programming-languages #memory-management #variable-shadowing