@niklaskorz If "safe" equals "not crashing", then memory leaks *are* safe to a certain point.
That is, no NULL pointer deference, no access to memory after it is freed, no access outside object bounds, etc.
Top-level
@niklaskorz If "safe" equals "not crashing", then memory leaks *are* safe to a certain point. That is, no NULL pointer deference, no access to memory after it is freed, no access outside object bounds, etc. 2 comments
@niklaskorz @matze I guess memory leaks are hard to catch at language level. The compiler cannot tell whether memory that's still referenced continues to be used. I also moved from Zed back to VSCodium, but for a different reason: I miss several features I'm used to, so I decided to switch back and keep watching Zed's evolution. |
@christophberger @matze Semantically speaking I agree, but from a practical point of view, I always feel like there should be some kind of additional "are you sure you want to do this?" for functions like Box::leak.
Also it is probably unrelated to the issues Zed is experiencing, I can imagine the problem lies somewhere in their integration of language servers but also I don't want to dig so I'll just keep to vscode for now.