Comment by tialaramex

Comment by tialaramex 5 hours ago

3 replies

View on Hacker News

Things that live forever can be immutably borrowed, no problem.

So rather than a non-owning pointer, you'd just use a &'static here - the immutable borrow which (potentially) lives forever

Years ago it was tricky to write the "forever, once initialized" type, you'd need a third party crate to do it stably. But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever.

[If you need to specify some runtime parameters later, but still only initialize once and re-use you want OnceLock not LazyLock, the OnceLock is allowed to say there isn't a value yet]

Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one. They're like the snorkel on the 4x4 I see parked in my street. I'd be surprised if they've ever driven it on a muddy field, much less anywhere the snorkel would help.

A retained mode GUI looks like a hierarchy to me, how do you say it isn't?

jcranmer 4 hours ago

> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?

The problem with retained mode GUIs is that, while the widget tree is, well, a a nice hierarchical tree, the widgets and the data model often need mutable references to each other, and it's these cross-references that break the tree-based ownership model of Rust.

Reply View 0 replies
TuxSH 3 hours ago

> But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever.

This corresponds to a C++ feature that has been added in C++11 (and other languages have this too AFAIK); good for libraries but but this has a runtime performance cost.

Since C++20 you can use constinit, or std::construct_at to avoid static initialization woes entirely

> Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one.

True about C, and also true of most userspace applications.

However, the whole point of intrusive list (and other intrusive structures) is to flip the ownership relationship - the object owns the node, instead of the node owning the object. In other words, the intrusive list is a non-owning view over its elements. More importantly, they allow the same object to be present in multiple lists at once (as long as you add enough node hooks).

For example, you can have a pool-allocated Thread object that is simultaneously part of a queue of inactive threads of priority N, and also part of a wait queue for something else.

> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?

Right, I conflated it with the other examples, my bad; there it's because of shared mutable state, children elements needing to update their parents, and lack of inheritance in Rust

Reply View 0 replies