|
|
Subscribe / Log in / New account

Rust 1.80.0 released

Version 1.80.0 of the Rust language has been released. Changes include the new LazyCell and LazyLock types (which delay data initialization until the first access), the stabilization of the exclusive-range syntax for match patterns, and more.

to post comments

size_of and align_of

Posted Jul 26, 2024 0:02 UTC (Fri) by josh (subscriber, #17465) [Link] (5 responses)

I'm really happy about the addition of LazyCell and LazyLock, which means projects can use the standard library rather than needing third-party crates like lazy_static or once_cell.

One minor change I worked on that I'm really happy about: size_of and align_of are now in the prelude, so you can use them without importing anything.

size_of and align_of

Posted Jul 26, 2024 6:48 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (4 responses)

Ooh. I haven't been keeping up with the news. I have been gradually working on an implementation of "Towards an API for the Real Numbers" but in Rust. For those who haven't any reason to have investigated, this is Hans Boehm's work which (in Java) for a while powered the Android calculator UI where 1/3 + 1/3 + 1/3 = 1 because duh, that's true, floats aren't how arithmetic actually works. It's "Towards" because of course the Reals are not at all well behaved in general, Almost All of them are entirely unsuitable for computers, including humans - however a lot of the ones we care about could be pretty well behaved if our API was better.

This week I got to the point where Hans' "Computable Reals" stuff is starting to work, so it not only knows that a sum adds up to, say, 4 pi, but it can produce a decimal approximation, stretching for perhaps a few pages I think if requested though the default is only 20 digits.

I think the Lazy features would help me write optimal code where I often need small "big" Integers, such as 4 (used to compute Pi on demand) and I'd love to be able to have a 4 "ready to go" but unlike ordinary integers the big integers I use have heap allocations so they can't just be ordinary constants. I had thought I should investigate the libraries once it was more complete and now I won't have to perhaps.

size_of and align_of

Posted Jul 28, 2024 2:23 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (3 responses)

Note that LazyCell and LazyLock are (for the most part) "just" a more user-friendly version of OnceCell and OnceLock, which have been stable since 1.70.0.

(The main difference is that OnceCell and OnceLock require you to pass the lambda at each callsite, whereas LazyCell and LazyLock let you pass it once at construction time. The other difference is that LazyCell and LazyLock are Deref, so the callsite doesn't look like a callsite, it just looks like a pointer dereference - but you can call the force() associated function if you really want to be explicit about it. The really pedantic difference that probably nobody cares about, is that OnceCell and OnceLock can give you a mutable reference to the underlying data if you have mutably borrowed the OnceCell/OnceLock, but the Lazy objects don't let you do that.)

size_of and align_of

Posted Jul 28, 2024 20:10 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (2 responses)

I think for my purpose the need to repeat the lambda everywhere is a problem, or at least a gross inconvenience. So that's why I think Lazy is important and I had not found Once adequate.

Basically instead of 4, a single byte with the pattern 00000100 in it, my four is: Two num::BigUints (a numerator and denominator) to form a rational magnitude, then a sign flag, a sum type which says whether we're also multiplying this by a fixed irrational value, and the potentially complicated arithmetic (with cached state, potentially very large) for the said irrational value if we are.

I would like to be able for the type of this data structure to provide something similar to a constant like FOUR and ZERO rather than (as I do in the current prototype) making such values each time they're needed.

This data structure is of course horribly unwieldy as a replacement for i32 or f64 - but it's perfectly reasonable for a desktop calculator type application, where the performance loss is more than amply compensated by knowing when there's an exact answer or it's in terms of a well known irrational such as Pi or e.

size_of and align_of

Posted Jul 29, 2024 2:58 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

I don't see why. You can just write this:

fn make_small_bigint(value: i64) -> BigNum{
// Do whatever simple logic you need here.
}

// Can also have e.g. make_small_rational(numerator, denominator), etc.

// Global scope:
static OnceLock<BigNum> FOUR = OnceLock::new();

// Callsite:
let four = FOUR.get_or_init(|| make_small_bigint(4));

LazyLock just means you can write let four = *FOUR; instead of let four = FOUR.get_or_init(|| make_small_bigint(4));. You still have to write the function make_small_bigint() either way, because you will need to pass exactly the same lambda to the LazyLock at construction time.

size_of and align_of

Posted Aug 1, 2024 15:02 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Yeah, exactly. You're correct that it's not *impossible* or even *actually difficult*, it's just messy and annoying and that's not enough improvement over my current situation, whereas Lazy is cleaner.

Don't worry, I was never under the impression it was *impossible* even when I started (long before 1.70) I was just expecting to need a third party crate to make this tidy and now probably I won't.

There's a lot more work to do to properly approach the vision from the Java API but in a nicer language, but I think I'm closing on the point where it's a useful alternative to tools like the Unix "basic calculator" bc or the typical GUI calculator on your desktop OS.


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds