Function pointers/delegates default args were stealth removed?

[Manu]

On 27 August 2012 03:51, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 8/26/2012 5:06 PM, Manu wrote:
>
>> type that is technically equivalent, but foo's type would have the bonus
>> default
>
> arg in its type record, just as a function pointer that were declared
>> explicitly.
>>
>
> That's the way it used to work. The problem is, what are those types? Are
> they the same types or not? You're saying sometimes they are the same type,
> sometimes they are not. It's a mess.


They are always equivalent. The default args are more like metadata.


At what point does the compiler become confused? They never interact... The
>> expected behaviour seems obvious to me, foo and bar should effectively be:
>>     int function(int a = 1) foo = ..;
>>     int function(int a) bar = ...;
>>
>
> It seems obvious only in the trivial case. What if you passed foo to a
> function? Now what type is it? What is the mangling for the type?


Well the function you pass foo to will define the type is receives.
If it receives by template, then it'll receive the default args, if it
defines the function pointer type it receives explicitly (or uses another
compatible definition), the default args may be lost (or different) in the
new instance across the function call.

I don't see why it needs to be mangled in. The linker doesn't care.


    The trouble for function pointers, is that any default args would need
>> to be
>>     part of the type, not the declaration.
>>
>>
>> I thought they were part of the type already? I would have thought that's
>> where
>> they should be. Why is their new home more 'proper'?
>>
>
> Because are the types the same or not?
>

They're equivalent, but not identical; one has some metadata the other
doesn't have.


    I know it broke code (for many others, too), and I'm very sorry about
>> that,
>>     but I don't see another way out.
>>
>>
>> It's a rather major breakage. I've seen you reject far more important
>> changes
>> solely on the grounds that they are a breaking change before...
>>
>
> Unfortunately, it was already broken, as the bug report showed. It's a
> matter of where the crack shows up.
>

Does the bug report actually demonstrate how it was causing anybody any
problems? It seemed a rather contrived scenario that just illustrated that
there was a bug.
Also, I think it could be fixed so the scenario in the bug report worked as
expected (I still don't understand why it did't work in the first place).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120827/38548f8d/attachment.html>