1. I'm fairly certain you have to use make to get into heap.

2. Odin 0s out memory when declaring a variable unless you explicitly state so with ---. This defines the state of memory when allocated.

▲

tialaramex 6 days ago | parent [-]

Ordinarily you'd be correct that you need the weird make overload, but I had no cause to invoke make I just told Odin that we don't care and it's fine, check the first line. Whether that feature is a good idea in this language I couldn't say.

Odin's decision to zero initialize local variables isn't relevant here.

▲

ixwt 6 days ago | parent | next [-]

Huh. Wasn't aware of that feature. Good to know.

I didn't fully flesh out the initializing local variables: What part of your code is undefined? You deleted the memory, and the compiler reused it. Then you re-accessed that same memory. That's just part of working with computers. The initialization comment was supposed to be from creating data to releasing it is defined. To be compliant with the Odin compiler spec, it's defined from start to end.

	▲	SkiFire13 6 days ago \| parent [-]
		Not OP but: > What part of your code is undefined? Using a variable (`some_map` in this case) after `delete`ing it doesn't seem something languages usually define in their specification. Does Odin define that?

▲

krig 6 days ago | parent | prev [-]

I don't really get the distinction between adding the dynamic-literals feature flag and using unsafe in Rust? Like, if he had called it #+unsafe dynamic-literals, would that have been better?

▲

tialaramex 6 days ago | parent | next [-]

I'm going to guess that you've never written, and perhaps never read, any unsafe Rust, because you (in common with several Rust critics) seem to be imagining it like a switch you can turn on somehow to disable the safety rules, and that's not what it is at all.

This Odin feature flag just allows me to write what I meant in Odin, I can write it all out by hand using make and so on without the feature flag, but it's more annoying to spell that all out which presumably was the impetus for this feature flag in the first place. The flag didn't somehow "cause" the unsafety, that's an insane take.

Odin isn't very well documented, so as somebody who was writing Odin just to explain the problem here, the easier option avoids trying to guess which of a dozen undocumented functions with names that may be related to hash maps is the "right" function to do what I meant, I can just write what I meant and turn on the feature flag to acknowledge that it involved allocation.

▲

krig 6 days ago | parent | prev [-]

I can't reply to the reply to this one (guess the thread is getting too deep), but I just wanted to clarify that I'm not a rust critic, I use rust, I like rust, I have no problem with rust. OK great, moving on...

	▲	tialaramex 6 days ago \| parent [-]
		The lack of reply is probably because the thing you wanted to respond to was new. This is a deliberate HN behaviour to discourage frantic conversations, like you might have if this was a Zoom call for example, or we'd had this disagreement in a bar (presumably a bar where there's a Compiler Explorer built in, or maybe literally Matt Godbolt is sat there with a laptop?) Maybe it works? I have had some positive experiences. If you know unsafe Rust the comparison to this Odin feature feels odd, but OK. Surely the Odin feature is more like when let-chains was unstable but you could tell the Rust nightly compiler you want that feature anyway ? Or... explicit_tail_calls which gives you a way to write explicit tail calls† in nightly Rust ? † This is a very cool feature if you're a functional programmer using the "become" keyword, you get tail call optimisation but it's mandatory, if what you've written can't work as a tail call then it won't compile, if it could work it does.