131–140 of 164 posts
On trees: Can you use regular references for the children, and weak references for the link back to the parent? That's a valid structure that tears down properly. With strong backpointers, when one of the objects is deleted, there's a moment when there's still a live reference to it. That's invalid under Rust's rules, so you can't do that. There's also the option to own all tree objects with some collection for alloc…
I have been feeling that way ever since two years ago when I first looked at the language. I still don't understand why this language has such popularity. It's really bad for the reasons mentioned. C++ is a solid language where you can do everything you want and also write memory safe code in a clean way with unique_ptr. C++ is not perfect but to me no alternative come close yet, rust and go comprised.
The solution linked to in "Go has a suitable answer" isn't relevant, because it doesn't support virtual methods. You can do the same thing described there in Rust by having a base struct, embedding the base struct in any child structs (composition over inheritance), and implementing Deref/DerefMut on the child if you like. Go has the exact same set of features Rust has here, no more: struct composition or interfaces/…
" Regarding graphs: The best solution is option 3, using a crate on crates.io (petgraph is the most popular, but rust-forest is fine too). " Or, couldn't you have a vec that owns the nodes and use indices instead of pointers? Or use pointers with the lifetime of the vec?
I don't know anything about Rust itself but I find it amusing that the author thought that six months should have been more than enough time for the community to agree on and implement a nontrivial change in how the language works.
I might be wrong but judging from this, I felt like we might never reach a conclusion on this topic even in a considerably long enough time, since it did seem to me that the core team is not interested in this feature.
From this point of view, I don't think it matters too much when we debate if six month is long enough, even if we waited longer, I'm not sure if the situation is gonna change when interest in this feature stays low.
On trees: Can you use regular references for the children, and weak references for the link back to the parent? That's a valid structure that tears down properly. With strong backpointers, when one of the objects is deleted, there's a moment when there's still a live reference to it. That's invalid under Rust's rules, so you can't do that. There's also the option to own all tree objects with some collection for alloc…
You don't need weak references. Just use strong ones.
Rust seems to be a poor match for the way the author wishes to solve this particular problem. That doesn't mean that their design is wrong, or that Rust is wrong, but it does mean that mixing the two would require rethinking parts of the design. > So a trait can define abstract functions, but can't access any underlying fields. In Rust, a trait is a purely abstract interface to a type. It explains how you can use tha…
> GUI libraries are an interesting special case > traditional object-oriented GUI designs may be awkward For example, Qt has moved that tricky part into a specialized language. I think that it's the way to go. So it's okay if a low-level language is not designed to do that ancient stuff with pointers to widgets.
Oh cool an anti-pattern being described as an "easy solution".
Earlier quoted context omitted.
Granted, current GUI toolkits are huge. On the other hand, I have worked with Qt, and this convinced me most of the complexity there was a blend of avoidable bloat and a long tail of features few people ever use (a bit like offices suites). I'm pretty sure properly written GUI toolkits can be much smaller. As in, satisfying 90% of our needs in a couple thousand lines of code. (The remaining 10% might require heaps an…
I'm pretty sure properly written GUI toolkits can be much smaller... Given that as far as I know, there are no examples of tiny fully-featured GUI libraries (it's all either trivial like cgui or a massive bloated mammoth like qt/wpf/android), isn't that a bit of a rich statement? Like, I'm sure you can write a procedural generator in a handful of lines of code that spits out the full works of Shakespeare. It's probab…
I'm pretty sure we haven't explored the sheer depth of simplifications that can still be done.