Function pointers/delegates default args were stealth removed?

[Manu]

On 27 August 2012 17:51, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 8/27/12 7:03 AM, Manu wrote:
>
>>     If we can take agreements each other about them, it may be supported.
>>
>> +1 for Kenji :)
>>
>
> I think the matter here is that we're looking at adding very significant
> complexity to the language for a feature with at best minor, marginal
> benefits.
>

... what?
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.
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.

Does the dmd implementation define the D language?

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 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.


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?
The fact the bug even exists implies that someone saw value in the feature
in the first place...

I'm not sure how you define 'power', but default args certainly offer
convenience. It also allows the default to be changed universally in one
place.
I wouldn't want to find the location of all calls to the function, and then
reason whether their manual placement of the default arg at each instance
is as a conventional default (such that I should update it to the new
default), or whether they explicitly intend that value in this particular
case.


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. 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.


On 27 August 2012 17:53, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>
 wrote:

> On 8/27/12 7:34 AM, Manu wrote:
>
>> Yes, I suggested this as a possibility above, but nobody commented. It
>> seems like it might solve 2 problems with one stone ;)
>>
>
> Whilst I agree a metadata facility is an interesting topic to look into, I
> think default arguments for functions is a poor motivating example.


I agree. It was just an interesting parallel that I noticed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120827/9f8f7e48/attachment-0001.html>