Bug 8752 – Unsafe use of T.init should be allowed in @system function

I think that T.init should be always legal expression for any T. But, I also agree that T.init _sometimes_ *unsafe*. 1) If T has @disable this(), T.init will returns an object which just initialized (== the value itself is never undefined), but not constructed (might be logically invalid object). 2) If T is nested struct, it's frame pointer is always null. It might cause access violation by its member function call. To relax the dilemma, I'd like to propose following restriction which enforced by the compiler. If T.init is unsafe (T is nested struct, or has @disable this();) , it will be annotated with @system, then could use it only inside @system and @trusted functions.

Given that using init is _almost_ always safe and that functions are @system by default, I don't know how good an idea this is. It will be _really_ easy for someone to use T.init with @disable, not realizing what they're doing. If @safe were the default, then maybe, but this just seems too dangerous to me. I could see an argument for always being able to use T.init in template constraints and the like, but it seems to me like it's going too far to allow @disabled init's to work in @system code. And depending, allowing T.init in template constraints and other metaprogramming poses its own risk, because while T.init often used to determine stuff about a type without actually using T.init in the code, there's no way to know whether the purpose of the test is to test something about T by using T.init or if the purpose is to test whether T.init itself actually works in they way that the constraint is testing for. So, I'm inclined to think that we need another solution for this.

Data cannot currently be marked as @system. This would be a pretty significant change. Anyhow, I don't think this is an @safe problem. Null pointers are the worst that can happen, and @safe doesn't cover that. Neither is a "logically invalid object".