On 8/27/12 8:46 AM, Manu wrote:
We're not talking about /adding/ anything, we're talking about a bug.
The scenario given in the bug report isn't even theoretically flawed, it
should work fine under the existing design (hence the bug report), but
it seems some design changes may a) make more sense, and also b)
simplify implementation/fixing the bug.
My understanding is that the bug revealed serious incompleteness in the
underlying design of the feature; fixing them properly would be a major
effort that (in my opinion) is not justified by the gains from the feature.
That seems fine, but rather than fixing said implementation bug, the
feature was just removed from the language, which was coincidentally a
major breaking change.
I agree that being a breaking change gives the issue a larger weight.
Does the dmd implementation define the D language?
No, and I wouldn't know why one would think I asserted otherwise.
I'm sure there's lots of bugs in various features that could be solved
by removing the feature completely.
I encounter problems using 'ref' and 'in' all the time...
The matter at hand here is the value of the feature in proportion to its
difficulty of implementation, prevalence in code, etc. I don't think it
would be e.g. realistic to drop ref for the language, although clearly
it would simplify it.
The feature was obviously intended, someone took the time to put it
there in the first place, and people use it.
It's implementation is apparently not perfect, and needs to be
clarified, maybe that requires a design tweak. That seems more what
Kenji is talking about to me.
It does. Also, Kenji found a variety of issues that have no clear
solution. I think there's no need for me to argue that features that
"almost work" are not a good way to go, even though they are useful when
they work.
Default arguments add no power to the language, you can quote me on
that.
Did I mention that _every project_ I've written in D is broken? Why have
I used a feature so much if it offers nothing?
I agree that your use of the feature and the subsequent breakage are
good arguments in favor of keeping the feature. Yet I know for
experience the feature's benefits are just marginal, and I am appealing
to you to look into alternative implementations using the rest of the D
programming language. I am convince you should find some. (Again, I
agree that having to change once working code remains a tall order.)
A wrong was fixed with a simplifying solution. That broke some code.
Granted, the code could be made to work with a much more complicated
(and complicating) solution. Is it worth it? At this point in D's
development, do we want to go full-bore about something that
complicates the language to very little benefit, particularly
considering we already have so many balls in the air? I think it's
reasonable to look into fixing the code and calling it a day.
A 'wrong'? What a subjective opinion.
Actually, no. By "wrong" I meant the bug itself.
Default args are useful, and I
absolutely appreciated the uniformity D seemed to offer in this respect
(ie, all kinds of function definition supported them).
How do you define 'fixing the code'? The 'fix' is a major breaking
change. Usually people are extremely phobic of the possibility of
breaking changes in even minor cases, yet this is relatively severe.
Far more important changes have been rejected on the grounds that
they're breaking changes alone...
If a solid solution is too difficult to implement, or isn't worth the
time right now, then just put the bug back. It was such a minor bug in a
very contrived case, and better than the fix.
If experience with language design taught me anything, it is that
contrived cases must be paid utmost attention. They are proofs that
something is wrong.
Andrei
