August 27, 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

August 27, 2012
On 2012-08-27 17:46, Manu wrote:

> Does the dmd implementation define the D language?

No one really knows. It's probably a mix of dmd, dlang.org and TDPL.

-- 
/Jacob Carlborg
August 27, 2012
On Monday, 27 August 2012 at 14:53:24 UTC, Andrei Alexandrescu wrote:
> On 8/27/12 7:34 AM, Manu wrote:
>> On 27 August 2012 17:03, foobar <foo@bar.com <mailto:foo@bar.com>> wrote:
>>
>>    This discussion is all sorts of wrong. Whoever said that defargs are
>>    metadata (Manu?) was right. Therefore it would make sense to
>>    implement a general metadata facility for D and use *that* for
>>    defargs. C++11 has annotations, so that's the place to start looking
>>    at. D has already enough of those pesky special case features, let's
>>    not add yet another one at the expense of a more general
>>    metadata/annotation mechanism which eventually would be added anyway
>>    due to popular demand.
>>
>>
>> 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.
>
> Andrei

The point was that there are _other_ motivating examples for annotations hence there's already popular demand for it. Which is why it's worth the added complexity to the language. In fact part of that complexity *already* exists in D syntax via built-in annotations (e.g @safe).
This same feature (annotations) can be leveraged to solve this small corner case hence it shouldn't be implemented separately and complicate both D and DMD for little gain.

August 27, 2012
On Mon, 27 Aug 2012 13:19:11 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 8/27/12 8:46 AM, Manu wrote:
>> 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.

That's not true, Kenji asked how the feature should behave in certain cases, and I answered every one of them.  There is a clear and valid solution.

Whether it's worth implementing or not is another question.  I think if it's not implemented we can come up with a very clunky library solution, but I'd rather see the compiler do it.

-Steve
August 27, 2012
On 8/27/12 11:08 AM, Steven Schveighoffer wrote:
>> 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.
>
> That's not true, Kenji asked how the feature should behave in certain
> cases, and I answered every one of them. There is a clear and valid
> solution.

What's missing is "simple".

Andrei
August 27, 2012
On Mon, 27 Aug 2012 14:45:54 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 8/27/12 11:08 AM, Steven Schveighoffer wrote:
>>> 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.
>>
>> That's not true, Kenji asked how the feature should behave in certain
>> cases, and I answered every one of them. There is a clear and valid
>> solution.
>
> What's missing is "simple".

Simple as in simple to understand, or as in simple to implement?  I think it's pretty simple to understand, especially if you understand default arguments in existing contexts.

But that is a subjective measure.

-Steve
August 27, 2012
On 8/27/2012 3:34 AM, Artur Skawina wrote:
> On 08/27/12 10:24, Walter Bright wrote:
>> On 8/27/2012 1:10 AM, Manu wrote:
>>> I don't see how the linker enters into it. Default args are irrelevant to the
>>> linker.
>>
>> Consider name mangling and what it's for. Now consider two *different* types mangling to the same name.
>>
>> D fundamentally depends on a 1:1 correspondence between types and name mangling, not 1:n or n:1.
>
> D or DMD?

D.

> Because the relevant bug /was/ an implementation problem.

Which revealed a design problem in the language.


> but that's not really an acceptable solution, obviously.

Right, and having a bunch of half-assed solutions is not a good long term solution. We all know that C++ is full of such, and they've caused endless grief as subsequent designers try to fix them, and pages and pages of impenetrable explanations in the C++ spec.


August 27, 2012
On 8/27/2012 4:46 AM, Timon Gehr wrote:
> What is the point?


For that case, there is none, as you should be passing the lambda by alias rather than by pointer.

August 27, 2012
Le 27/08/2012 00:41, Walter Bright a écrit :
> On 8/26/2012 3:26 PM, Manu wrote:
>> I just updated to 2.60 and found errors throughout my code where function
>> pointers default args no longer work.
>> _Every single project_ I've written in D, 5 projects, don't work anymore,
>> including my projects at work.
>>
>> I found this discussion:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3866
>> It seems the change was just decided and implemented with basically no
>> discussion or argument at all :/
>>
>> My use cases are dynamic linkage, and cross-language integration.
>> I can't manually interact with DLL's containing API's that expect to have
>> default arguments if function pointers no longer support them.
>> Also when receiving foreign language function pointers, they
>> frequently need to
>> have default args too.
>>
>> I also integrate with many C style API's (rendering engines and the
>> like), which
>> involve registration of various callbacks, and lots of those have
>> default args too.
>>
>> I find this particularly surprising, since I recently motivated
>> implementation
>> of new traits which could parse default args from parameter lists, and
>> use that
>> to generation function pointers in templates which auto-magically clone
>> functions parameter lists verbatim, specifically including the default
>> args...
>
> The trouble is that, as 3866 shows, there is no design anyone could come
> up with that worked in a consistent manner. The only consistent way out
> was to make default arguments a characteristic of the declaration, not
> of the type.
>
> The trouble for function pointers, is that any default args would need
> to be part of the type, not the declaration.
>
> I know it broke code (for many others, too), and I'm very sorry about
> that, but I don't see another way out.
>
> (Many uses of default arguments can be replaced with overloaded functions.)
>

That guy just have to rework 5 projects. This is quite a lot of work.

Obviously, that change have to be done. But you can't just impose such a change on users. Their agenda isn't synchronized with D's.

D NEED a better versioning scheme, as explained MANY times here already.
August 27, 2012
Le 27/08/2012 19:19, Andrei Alexandrescu a écrit :
>> Does the dmd implementation define the D language?
>
> No, and I wouldn't know why one would think I asserted otherwise.
>

You didn't, but I'd be foolish to assert otherwise.