3 ms·

Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff (https://nim-lang.org/araq/ownedrefs.htm

Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff (https://nim-lang.org/araq/ownedrefs.html https://nim-lang.org/araq/ownedrefs.html) had been part of 1.0, but I think that at some point shipping 1.0 >> everything else. I've been following (and evangelizing) Nim for a while, this will make it easier to do so.

treeform 7y ago
I don't think the owned reference part will change the language drastically. For people that want to write kernels, games or real time code it would be great. Nim's GC is super configurable already. Yeah owned reference would be better but its already pretty good.
Clyybber 7y ago
It is part of 1.0, but you have to enable it using the "--newruntime" build switch.
ptx 7y ago
I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption? If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption? If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.
- loeg 7y ago
  It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization. It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety. You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.
- uryga 7y ago
  i guess the argument is that you'll never read random garbage instead of a well-formed object; and given that random garbage could result in pretty much arbitrary "undefined behavior", it should at least guarantee that your program will behave roughly as intended, even if giving incorrect results (i'm not convinced that's a useful thing myself)
  - littlestymaar 7y ago
    > and given that random garbage could result in pretty much arbitrary "undefined behavior" Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.
    - uryga 7y ago
      i put it in quotes because i meant "arbitrarily weird side-effects", but you're right that i should have used a different term

treeform 7y ago

I don't think the owned reference part will change the language drastically. For people that want to write kernels, games or real time code it would be great. Nim's GC is super configurable already. Yeah owned reference would be better but its already pretty good.

Clyybber 7y ago

It is part of 1.0, but you have to enable it using the "--newruntime" build switch.

ptx 7y ago

I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption? If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption? If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.

loeg 7y ago
It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization. It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety. You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.
uryga 7y ago
i guess the argument is that you'll never read random garbage instead of a well-formed object; and given that random garbage could result in pretty much arbitrary "undefined behavior", it should at least guarantee that your program will behave roughly as intended, even if giving incorrect results (i'm not convinced that's a useful thing myself)
- littlestymaar 7y ago
  > and given that random garbage could result in pretty much arbitrary "undefined behavior" Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.
  - uryga 7y ago
    i put it in quotes because i meant "arbitrarily weird side-effects", but you're right that i should have used a different term