Re: type based aliasing again

[Richard Stallman <rms at gnu dot org>]

	Joe> A).  If we detect a rule violation, issue a warning and tell
	Joe> the compiler to assume aliasing.

	Joe> B).  If we detect a rule violation, issue a warning and tell
	Joe> the compiler to assume no aliasing. (That is, produce bad
	Joe> code).

	Joe> C).  If we detect a rule violation, issue an error and don't
	Joe> go on.

	Joe> I think that only A) and C) are reasonable.  B) is not.  I
	Joe> would prefer A).

Mark wrote:

    There will be cases where A will pessimize code that does not have
    undefined behavior.  So, in fact, C is impossible, and A penalizes
    conforming code.  Thus, B is the only remaining sensible option.

This reasoning is based on an assumption about priorities: that
efficiency is far far more important than not breaking users' code.

Those priorities are not well chosen.  Efficiency is important because
it makes users happy.  Not breaking users' code is important because
it makes users happy.

In general, they are both important.  But they are not (in general)
equally important in how they affect any specific issue.  To decide
each issue, we have to look at how MUCH efficiency is to be gained and
in which cases, how MANY (and which, and how important) cases will
break, and so on.  That way we can estimate how each alternative will
affect the users.

In this specific issue, we can unbreak many programs, with almost no
penalty in efficiency.  In this specific issue, unbreaking the
programs wins.  In another issue, it might be the other way around.