Vision for the D language - stabilizing complexity?

[ag0aep6g via Digitalmars-d]

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.