On 05/21/2013 10:40 AM, Maxim Fomin wrote:
On Monday, 20 May 2013 at 23:10:48 UTC, Timon Gehr wrote:
...
In some notorious cases such artificiality created
problems (for local convenience at the expense of language consistency)
I don't see how this is relevant. The compiler behaviour is at the
expense of language consistency, as I have argued above.
are not easy to fix (ref), or are unfixable by design (@disable), or are
broken and dumped without touch for ages (delegates).
I disagree with those assertions.
What is the conceived issue with delegates?
Conceived issue is that they are holes in type system (unlike
casts and unions they are not supposed to be), let alone there
numerous bugs related to their implementation. See Bugzilla for
particular examples.
I see. I reported a few of those recently. Some of them got fixed.
Clearly, bugs should not stop from implementing a good feature, but here
I see low benefits and some problems.
...
This is not about implementing a new feature. This is about fixing an
implementation bug. Otherwise the compiler behaviour would need to be
carried over to the spec. Doing nothing about it is not valid.
You *think* that it is a bug and this cliam is not necessaruly
true.
A compiler bug is a discrepancy between spec and compiler. It is a bug
given the current spec.
According to spec you are promised to have a.foo(b) from
foo(a,b) but you are not promissed to have anything beyond that
The fundamental problem is obviously that the "spec" is not fully
unambiguous, but consider:
https://en.wikipedia.org/wiki/Abstract_rewriting_system
You are free to disagree by using different than usual fundamental
notions, but if those are to be used by the language, they need to be
defined by the spec.
E.g. we'd need to introduce hidden state into the AST: Rewritten code
would not be D code anymore, which removes most of the benefits of using
rewrite rules for specification in the first place. (but given that the
rewriting system given by the various rules from the spec does not
appear to be confluent, this is a moot point anyway.)
(including several stages of rewrite for operator overloading).
Given the assumption that the spec implies a limit on the number of such
"stages", why would the limit be 1 and not 2 or 3? Why not even other
numbers?
Please stop presenting a POV as absolute truth.
Mathematical truth. To disagree with it you'd either:
[1] Question the axioms or definitions.
=> In this case, my argument is valid, but this is not relevant for
=> you. I guess most of the arguing about language features goes on in
=> this section. To settle disputes here, concrete examples showing
=> the merits of your own viewpoint are usually useful.
[2] Show a flaw in reasoning.
[3] Be wrong.
