TWiR quote of the week

<pnkfelix> what is our formatting style for a boolean `a && b && c` where I need to break the line in the middle? 
<pnkfelix> in particular, do I do the break after one of the `&&`, or before it?
<WindowsBunny> pnkfelix: I personally put && after the newline, but I'm also apparently several standard deviations away from normal
<pnkfelix> WindowsBunny: clearly the answer is to support breaking the line between `&` and `&`; that would make everyone happy, right? ;)

https://botbot.me/mozilla/rust-internals/2017-10-11/?msg=92169028&page=2

8 Likes

Rust is like English, just with more turbofish.

Xion_ on the #rust irc channel. (https://botbot.me/mozilla/rust/2017-10-19/?msg=92498115&page=13)

7 Likes

from #rust-offtopic:

 <kiwi> So how did Rust's borrow checker get invented and was it there since the very beginning?
 <kiwi> Because it's a really good idea
 <panicbit> We just unsafely borrowed it from the future
15 Likes

And that is actually supported :open_mouth: https://play.rust-lang.org/?gist=23ebc666f4ab8b7b2ce9a2fcdf4abf13&version=stable

4 Likes

Clippy catches it:

warning: taken reference of right operand
  --> src/main.rs:14:5
   |
14 |     a() & & b();
   |     ^^^^^^-----
   |           |
   |           help: use the right value directly: `b()`
5 Likes

From this AMA :

I guess I would say that, it’s not only important that it be possible to do a good design in a given language, but that the language actively encourage it by making the bad design painful. I think rust does a FANTASTIC job of this.

9 Likes

#rust:

<m4b> i’m writing generic code so generic right now i don’t know how its working, but it does

Referring to this code.

5 Likes

https://github.com/rust-lang/rust/pull/45501#issuecomment-340159627:

assume is dark magic of the higher schools, so I’m not surprised there are sparks. I think it’s best to not use it unless absolutely necessary.

@bluss

3 Likes

Is something wrong with me if that description actually made me want to look up this assume thing? :stuck_out_tongue:

1 Like

On #rust-internals wrt. https://github.com/rust-lang/rust/pull/45527

durka42 IMO the name “dangling” is scary enough :slight_smile:
Havvy gives durka42 a ptr::dangling::<Candy>().
durka42 declines to unwrap() it

https://botbot.me/mozilla/rust-internals/2017-11-02/?msg=93047552&page=2

6 Likes

A brilliant observation by @kickass_turing on reddit about Rust code being refactoring friendly:

Also the way I see it is that Rust makes problems local.

3 Likes

Another nice example of the “lisp effect”, where learning one language makes you better in another :slight_smile:

5 Likes

I think x & & y is still, unfortunately, different from x && y.

See: https://play.rust-lang.org/?gist=a798c8cc4a6f64a6d3317329dbe86834&version=stable (x & & y is really just x & y, which doesn’t short-circuit boolean logic)

1 Like

I’d think & & should just flat-out be an “expected expression, found …” error like it is with 1 + + 2.

x && y makes sense and x & &y is meaningful as "bitwise AND together x and the auto-deref-coerced value of y" , but x & & y looks like it’s guaranteed to be a typo-induced bug.

Such arbitrary introduced whitespace sensitivity is the death of automatically generated code, though (think macros).

Point, but it should at least be a warning. (And that’s assuming that rustc can’t just handle macro-generated code differently in that case and force any re-serialization of the AST back to the spaceless form.)

When I look at 5 & & 5, I don’t see 5 BitAnd Borrow(5). My intuition is to see it as some weird no-op pass-through special-case of (5 BitAnd) BitAnd 5 or 5 BitAnd (BitAnd 5).

Heck, until I actually looked into what x & & y was doing, I firmly believed that the compiler only parsed & as a borrow operator if there was no whitespace between it and what follows.

(ie. “&'s status as a unary operator is determined by whitespace” won out in my intuition despite my knowing that - as a unary operator is not whitespace sensitive in Rust. I believed that separating them was like writing ma tch { rather than match {)

Who knows how many other “at most, one semester of C and C++ combined back in the hazy days of university” programmers will make that mistake.

I know what you mean, but for me this is just too much guesswork on the compiler’s part. As far as I know, whitespace between tokens does not matter anywhere in Rust right now. (Also, not all generated code comes from macros.)

It’s not like making the mistake will get you a typechecking program that only misbehaves at runtime. In contrast to similar issues in dynamic languages, such as the “interesting” case a in b < c in Python.

[please insert kind reminder to move these discussions into a new thread]
Thank you very much ladybugs and gentlecats.

4 Likes

“Although rusting is generally a negative aspect of iron, a particular form of rusting, known as “stable rust,” causes the object to have a thin coating of rust over the top, and if kept in low relative humidity, makes the “stable” layer protective to the iron below”

From: https://en.wikipedia.org/wiki/Rust

17 Likes

I assumed someone made a recent change in Wikipedia in a jest.
So I tracked the change in Wikipedia, and it is more than a year old.
The WIkipedia diff.

3 Likes