Timon Gehr:
> The problem is that generated/CTFE'd code might produce that kind of
> redundancy.
Right.
> Proving that two sub-expressions are equivalent is a hard task.
A simple equivalence is enough here: the code with normalized whitespace. Those
tools are probably doing something not much complex than this.
> Has anyone ever
> experienced a bug that was hard to find similar to those toy examples? Well,
> maybe
> if(x||y||z||a||b||x||d){/*do stuff*/}, but who writes such code?
The examples I've shown are present in real code. See the results of the
Coccinelle project too.
> But if a programmer wants to use it, he has
> to be familiar with its precedence rules (very simple, lower precedence than
> anything but = and ,).
In computer languages there are plenty simple things that are bug-prone.
> I as an excessive user of ?: am very much against it though.
It's not advisable to use the ?: operator a *lot* :-)
> I think requiring parentheses (providing undefined or ambiguous precedence
> rules)
> is ugly. D has done it before and it seems reasonable to do so, but still
> ugly.
I don't see better solutions given the D Zen contraints. And in this case
adding parentheses may be better than doing nothing.
If you have some comments about this bug #1, a good place to add them is here:
http://d.puremagic.com/issues/show_bug.cgi?id=5409
> It also implies that the precedence rules would be a design mistake if not
> for compatibility with C.
I don't fully understand.
> What property makes them so bug-prone?
I am not sure, but I think it encourages a too much compact code style (and you
have to be a bit careful with operator precedence too). Probably there is some
optimum for compactness of C-like code. The sources of the first J interprer is
surely too much compact, and some C# code I've seen seems not enough compact to
the point of not allowing an easy read.
> I think they are quite easy to use.
Right, the ?: operator is easy to use.
Thank you for your comments, bye,
bearophile
