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? ;)

Rust is like English, just with more turbofish.

Xion_ on the #rust irc channel. ( + Startup Resources | Startup Resources)


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

And that is actually supported :open_mouth: Rust Playground


Clippy catches it:

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

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.



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

Referring to this code.


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.



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.

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


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.


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


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

See: Rust Playground (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.


"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: Rust - Wikipedia


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.