On 07/08/2016 08:42 PM, deadalnix wrote:
It is meaningless because sometime, you have A and B that are both safe on their own, but doing both is unsafe. In which case A or B need to be banned, but nothing allows to know which one.
Would you mind giving an example? Purely to educate me.
This isn't a bug, this is a failure to have a principled approach to safety.
The principled approach would have been to start with an empty set of features in @safe and then add stuff after verifying that it's safe on its own and in combination with what's already there. Right?
If that's it, then that does seem better to me, yeah. But I'd say that the unprincipled approach has led to bugs (or maybe call it holes in the spec).
And what I tried to say is that the dictatorship at least acknowledges those bugs/holes and agrees that they need fixing. Whereas they're apparently just fine with the silly limitation of alias parameters that you pointed out.
The position is inconsistent because the dictatorship refuses to compromise on mutually exclusive goals. For instance, @safe is defined as ensuring memory safety. But not against undefined behaviors (in fact Walter promote the use of UB in various situations, for instance when it comes to shared). You CANNOT have undefined behavior that are defined as being memory safe.
What you say makes sense to me. Seems silly when the compiler guards me against memory-safety errors but not against undefined behavior.
