3 ms·
Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't
by estebank 3y ago
Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't specify a preference, should its math operation be safe or unsafe? If the former, this makes it likely a better default, but limiting in its usefulness. If the later, then your compiler now has to keep track of this information for the entire call graph.
- throwawaymaths 3y agoThe form of safety we are talking about here is not like rust's "safety", it does not color functions, and is strictly scoped to the compiled unit (in this case, function) https://ziglang.org/documentation/master/#setRuntimeSafety https://ziglang.org/documentation/master/#setRuntimeSafety
- estebank 3y agoI am aware, my point is about how the following is dealt with: fn foo(x: i32) i32 { return x + 100; } fn bar(x: i32) i32 { @setRuntimeSafety(false); return foo(x + 100); } Particularly when you have arbitrarily deep call graphs where some explicitly enable and disable runtime safety.
- throwawaymaths 3y agoYou mean overflow checking? It only applies to the `x + 100` in bar. Bar can still panic if the `x + 100` in foo overflows. Why should it be any other way?