Function pointers/delegates default args were stealth removed?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Aug 27 10:19:11 PDT 2012


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



More information about the Digitalmars-d mailing list