« first day (3456 days earlier)      last day (1565 days later) » 

trollingchar
trollingchar
12:56 PM
Rust is a strange language. I implemented addition of points of different types, only that that types should support addition:

impl<A: Add<B>, B> Add<XY<B>> for XY<A> {
type Output = XY<A::Output>;

fn add(self, rhs: XY<B>) -> Self::Output {
XY::new(self.x + rhs.x, self.y + rhs.y)
}
}

But now it refuses to use variables after addition because they "moved".
 
nwp
nwp
I think there was a way to specify that you're only temporarily reading a variable and not borrowing it past the end of the function. It's likely that it's not Rust being strange but you having accidentally specified the wrong type of object passing.
I played with Rust a bit. It takes some getting used to.
 
trollingchar
trollingchar
Yes, I think there should be a way to borrow a variable instead of moving it
The easy way is making XY supporting copying
it's very small and I can afford copying it here and there
but I want to figure out how it works
 
nwp
nwp
Just put unsafe{} around it.
2
 
trollingchar
trollingchar
haha
 
user92578
1:41 PM
I never understood the safe/unsafe paradigm (all though I just looked at my friends coding in Rust, didn't try it myself), but as C libraries need to be wrapped in unsafe somewhere down the layers, it seems like any unsafe anywhere invalidates the whole safety of the rest of the program?
 
Elva
Elva
Only in the bits that are unsafe I expect. Not necessarily in anything else... though I'm talking about real world scenarios and not from a strict computer science point of view
 
user92578
Conceptually I can't seem to justify why the UB in the unsafe sections couldn't cascade onto safe sections
 
nwp
nwp
Unsafe sections are not allowed to contain UB. Rust just gives you guarantees automatically and when you write unsafe you are responsible to uphold the guarantees. If you do not enforce all of Rust's guarantees in your unsafe code it's UB and you're screwed.
Unfortunately Rice's theorem exists which states that you cannot make nontrivial statements (statements that are not always true or false) about the behavior of programs written in Turing-complete languages, so it's impossible to write an algorithm that always gets things like "can't dereference invalid pointers" right (unless you make it trivial by disallowing pointers or something). So there will always be false positives in the borrow checker.
Which is where the programmer comes in and manually checks that all guarantees hold despite the borrow checker being unable to prove it.
A typical example is a mutex. Rust only allows 1 mutable reference or any number of immutable references so you cannot write a data race. When implementing the mutex class you say "Yes, I give out multiple mutable references to different threads, but it's fine, I lock a mutex every time someone accesses it". The borrow checker is too stupid to understand that, so you have to do the checking manually. If you then decide not to actually lock the mutex hilarity ensues.
 
 
7 hours later…
trollingchar
trollingchar
9:00 PM
It's not that bad, only 37 LoC and it's finally possible to write let c = &a + &b; without moving a and b!
with macros maybe it would be even less
 
 
2 hours later…
Almo
Almo
10:52 PM
My comment on the CEO blog post
Scripting the Future of Stack Overflow
Prashanth Chandrasekar on January 21, 2020

As we enter a new decade, there are tremendous forces converging—cloud computing, big data, AI, ML, and an increasingly diverse group of young coders from around the world. Every day, millions of developers visit Stack Overflow to find information they need as they push these exciting new technologies forward. There has been a massive shift since my days as a computer engineering graduate. I was fascinated by the power of languages like Perl, but had only my teachers, classmates, and a few small web forums and mailing lists as a community to support my learning. The numbers below really put into perspective the impact that our community generates and the opportunities that lie ahead: …

 

« first day (3456 days earlier)      last day (1565 days later) »