Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.27.2

blog.rust-lang.org

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Announcing Rust 1.27.2

#21

Post by Animats »

kibwen wrote: post #16

To reiterate what the OP suggests at the bottom, the new (in-progress) borrow checker (the one designed from the ground-up to support non-lexical lifetimes (NLL)) suffers from none of the match bugs that have inspired the recent slew of patch releases. It does indeed appear as though the new match features were designed with the theoretical model of the borrow checker in mind, to which the new borrow checker hews muc…

Buzzwords:

OP: Original poster

NLL: Non-lexical lifetimes. New Rust feature. Actually, they're still lexical, in that they're bound to a specific section of source code. It's just that the lifetime region might be smaller than a block. Variables living too long is a problem in Rust because, if they're borrowing something, they block other uses of the same thing they're borrowing. See [1].

CFG: "Control Flow Guard"? Microsoft feature to prevent overwriting return points on the stack? Not sure about this one.

IR: "Intermediate representation", the data format used between compiler passes. Now broken down within Rust to a "high level representation" (HIR), a "medium level representation" (MIR), and a low-level representation. The low level representation is called LLVM, not "LIR", because it's borrowed from the LLVM system.

LLVM: Originally "Low Level Virtual Machine", now just an identifier for a a specific compiler optimizer and code generator.

[1] http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...

Re: Announcing Rust 1.27.2

#22

Post by muizelaar »

Animats wrote: post #21
kibwen wrote: post #16

To reiterate what the OP suggests at the bottom, the new (in-progress) borrow checker (the one designed from the ground-up to support non-lexical lifetimes (NLL)) suffers from none of the match bugs that have inspired the recent slew of patch releases. It does indeed appear as though the new match features were designed with the theoretical model of the borrow checker in mind, to which the new borrow checker hews muc…

Buzzwords: OP: Original poster NLL: Non-lexical lifetimes. New Rust feature. Actually, they're still lexical, in that they're bound to a specific section of source code. It's just that the lifetime region might be smaller than a block. Variables living too long is a problem in Rust because, if they're borrowing something, they block other uses of the same thing they're borrowing. See [1]. CFG: "Control Flow Guard"? M…

CFG: control flow graph

Re: Announcing Rust 1.27.2

#23

Post by tux3 »

Animats wrote: post #21
kibwen wrote: post #16

To reiterate what the OP suggests at the bottom, the new (in-progress) borrow checker (the one designed from the ground-up to support non-lexical lifetimes (NLL)) suffers from none of the match bugs that have inspired the recent slew of patch releases. It does indeed appear as though the new match features were designed with the theoretical model of the borrow checker in mind, to which the new borrow checker hews muc…

Buzzwords: OP: Original poster NLL: Non-lexical lifetimes. New Rust feature. Actually, they're still lexical, in that they're bound to a specific section of source code. It's just that the lifetime region might be smaller than a block. Variables living too long is a problem in Rust because, if they're borrowing something, they block other uses of the same thing they're borrowing. See [1]. CFG: "Control Flow Guard"? M…

Don't you mean acronyms :) ?

CFG would be Control Flow Graph, a structure compilers use to track all the possible paths through your code.

Re: Announcing Rust 1.27.2

#24

Post by pcwalton »

webaholic wrote: post #15
TheDong wrote: post #9

Earlier quoted context omitted.

If you're familiar with rust syntax, that function is readable: A function 'transmute_lifetime' that takes a tuple of generic type T with lifetime 'a and returns a T with lifetime 'b... And then the code itself, beyond the function signature, is trivial destructuring matching. If you're not familiar with the syntax of a language, of course it won't be easy to read. perl and bash can rapidly devolve into symbol salad…

and that is where the problem lies. All code is readable if you spend an hour or two. The point is that it is not lucid. You have to strain to understand such code. The issue is people thinking this code is acceptable.

That code is not "acceptable". It's not supposed to be. It's a compiler test case.

Re: Announcing Rust 1.27.2

#25

Post by eptcyka »

kibwen wrote: post #16

To reiterate what the OP suggests at the bottom, the new (in-progress) borrow checker (the one designed from the ground-up to support non-lexical lifetimes (NLL)) suffers from none of the match bugs that have inspired the recent slew of patch releases. It does indeed appear as though the new match features were designed with the theoretical model of the borrow checker in mind, to which the new borrow checker hews muc…

I was under the impression that the upcoming, shiny, great borrow checker is a tad slow, pathologically so in some cases. https://github.com/rust-lang-nursery/polonius But I do love the way they're tackling the issue know, as this is a much more generic solution.

Re: Announcing Rust 1.27.2

#26

Post by phyzome »

blackrock wrote: post #5

Sample Code: ======================= fn transmute_lifetime (t: &'a (T,)) -> &'b T { match (&t, ()) { ((t,), ()) => t, } } ======================= I thought Obfuscated-C was hard to read. Then C++ with all its templates. Now, I'm thinking Rust has taken the prize.

It's repro code for a compiler bug, of course it looks horrible.

Here's a similarly horrible Java example, from a recent HN post on Java's type system being unsound: https://twitter.com/joshbloch/status/822948565433466881

It's more verbose, because Java, but equally dense relative to the language as a whole.

This is not supposed to be good code.

Re: Announcing Rust 1.27.2

#27

Post by phyzome »

tux3 wrote: post #23
Animats wrote: post #21

Earlier quoted context omitted.

Buzzwords: OP: Original poster NLL: Non-lexical lifetimes. New Rust feature. Actually, they're still lexical, in that they're bound to a specific section of source code. It's just that the lifetime region might be smaller than a block. Variables living too long is a problem in Rust because, if they're borrowing something, they block other uses of the same thing they're borrowing. See [1]. CFG: "Control Flow Guard"? M…

Don't you mean acronyms :) ? CFG would be Control Flow Graph, a structure compilers use to track all the possible paths through your code.

Or perhaps initialisms (most of those weren't pronounceable), if we're being picky!

Re: Announcing Rust 1.27.2

#30

Post by kzrdude »

Animats wrote: post #21
kibwen wrote: post #16

To reiterate what the OP suggests at the bottom, the new (in-progress) borrow checker (the one designed from the ground-up to support non-lexical lifetimes (NLL)) suffers from none of the match bugs that have inspired the recent slew of patch releases. It does indeed appear as though the new match features were designed with the theoretical model of the borrow checker in mind, to which the new borrow checker hews muc…

Buzzwords: OP: Original poster NLL: Non-lexical lifetimes. New Rust feature. Actually, they're still lexical, in that they're bound to a specific section of source code. It's just that the lifetime region might be smaller than a block. Variables living too long is a problem in Rust because, if they're borrowing something, they block other uses of the same thing they're borrowing. See [1]. CFG: "Control Flow Guard"? M…

LLVM is just a name, now. See http://llvm.org/
Post reply on HN