On Thursday, 26 April 2012 at 03:44:27 UTC, Walter Bright wrote:
> A subtle but nasty problem - are default arguments part of the type, or part of the declaration?
>
>    See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>
> Currently, they are both, which leads to the nasty behavior in the bug report.

From what I would name "normative" view they should be the same type: function type is charcterized by return type and by number and order of parameters' types. Because both functions accept and return the same types they should be the same function type. On the other hand, D is an ongoing project and you are free to implement special behavior.

>
> The problem centers around name mangling. If two types mangle the same, then they are the same type. But default arguments are not part of the mangled string. Hence the schizophrenic behavior.
>

I think it should be done in reverse order: firstly decide whether they are the same or not, than apply mangling to the decision. Tail doesn't wag a dog.

> But if we make default arguments solely a part of the function declaration, then function pointers (and delegates) cannot have default arguments. (And maybe this isn't a bad thing?)

The bad thing is that we would need extra typing, the good thing is that if the declaration changes the bug wouldn't be hidden. That I find similar to the D policy of preventing function hijacking, etc.

On 04/26/2012 05:44 AM, Walter Bright wrote:
> A subtle but nasty problem - are default arguments part of the type, or
> part of the declaration?
>
> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>
> Currently, they are both,

That is how it should be.

> which leads to the nasty behavior in the bug report.
>

It contributes, but it is not the main cause.

> The problem centers around name mangling. If two types mangle the same,
> then they are the same type.

Then they are equal types.

> But default arguments are not part of the
> mangled string. Hence the schizophrenic behavior.
>

The schizophrenic behavior occurs because the types cross-talk. Are mangled names kept unique in the compiler or what is the implementation issue exactly?

> But if we make default arguments solely a part of the function
> declaration, then function pointers (and delegates) cannot have default
> arguments. (And maybe this isn't a bad thing?)

I think default arguments for delegates and function pointers are quite a feat.

The proposal is to change the language in a backwards-incompatible way based on implementation issues that shouldn't be that hard to resolve.

(Related: Template instantiation should strip off the default arguments from delegate and function pointer types.)

On 4/26/2012 12:47 AM, Timon Gehr wrote:
> On 04/26/2012 05:44 AM, Walter Bright wrote:
>> A subtle but nasty problem - are default arguments part of the type, or
>> part of the declaration?
>>
>> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>>
>> Currently, they are both,
>
> That is how it should be.
>
>> which leads to the nasty behavior in the bug report.
>>
>
> It contributes, but it is not the main cause.
>
>> The problem centers around name mangling. If two types mangle the same,
>> then they are the same type.
>
> Then they are equal types.

This is simply not tenable. What defines when they are "equal" types and when they are "not equal"? Consider a pointer to a function. Are the default arguments part of its type? If it compares "equal" to another type without default arguments, which is the real type (such as the result of ?:) ?


>> But default arguments are not part of the
>> mangled string. Hence the schizophrenic behavior.
>>
>
> The schizophrenic behavior occurs because the types cross-talk. Are mangled
> names kept unique in the compiler or what is the implementation issue exactly?

It's a conceptual issue. When is one type the same as another, and when is it not?

On 26/04/12 05:44, Walter Bright wrote:
> A subtle but nasty problem - are default arguments part of the type, or
> part of the declaration?
>
> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>
> Currently, they are both, which leads to the nasty behavior in the bug
> report.
>
> The problem centers around name mangling. If two types mangle the same,
> then they are the same type. But default arguments are not part of the
> mangled string. Hence the schizophrenic behavior.
>
> But if we make default arguments solely a part of the function
> declaration, then function pointers (and delegates) cannot have default
> arguments. (And maybe this isn't a bad thing?)

I think it is a mistake to allow default arguments in function pointers and delegates (it's OK for delegate literals, there you have the declaration).
I don't see how it can possibly work.

If it's really a type, then given:
void foo(int x = 2) {}
void bar(int y = 3) {}
then typeof(&foo) should be:   void function (int __param0 = 2)
I don't see how we could justify having those types and not using them.

But then, if you have:
auto p = &foo;  //  p has default parameter of 2
p = &bar; // Should this work?

I really don't think we want this.


As I vaguely remember someone saying about the bug report, it looks like an attempt to have a pathetic special case of currying syntax sugar built into the language.
But it isn't even as efficient as a library solution (if the construction of the default parameter is expensive, it will generate gobs of code every time the function parameter is called).

On 2012-04-26 05:44, Walter Bright wrote:

> But if we make default arguments solely a part of the function
> declaration, then function pointers (and delegates) cannot have default
> arguments. (And maybe this isn't a bad thing?)

Why not?

-- 
/Jacob Carlborg

On 04/26/2012 09:54 AM, Walter Bright wrote:
> On 4/26/2012 12:47 AM, Timon Gehr wrote:
>> On 04/26/2012 05:44 AM, Walter Bright wrote:
>>> A subtle but nasty problem - are default arguments part of the type, or
>>> part of the declaration?
>>>
>>> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>>>
>>> Currently, they are both,
>>
>> That is how it should be.
>>
>>> which leads to the nasty behavior in the bug report.
>>>
>>
>> It contributes, but it is not the main cause.
>>
>>> The problem centers around name mangling. If two types mangle the same,
>>> then they are the same type.
>>
>> Then they are equal types.
>
> This is simply not tenable. What defines when they are "equal" types and
> when they are "not equal"?

This is a matter of terminology. For example, for 'equal' just exclude the default parameters from the comparison. For 'the same' include default parameters in the comparison. (therefore, 'the same' implies 'equal')

> Consider a pointer to a function. Are the
> default arguments part of its type?

Yes.

> If it compares "equal" to another type without default arguments, which is the real type (such as the
> result of ?:) ?
>

The result of ?: is the type of the two arguments if they are the same, and it is the equal type without default arguments if they are not the same.

>
>>> But default arguments are not part of the
>>> mangled string. Hence the schizophrenic behavior.
>>>
>>
>> The schizophrenic behavior occurs because the types cross-talk. Are
>> mangled
>> names kept unique in the compiler or what is the implementation issue
>> exactly?
>
> It's a conceptual issue.  When is one type the same as another, and when
> is it not?
>

void function(int) is the same as void function(int) and both are equal
void function(int=2) is not the same as void function(int=3), but both are equal.

On 04/26/2012 10:51 AM, Don Clugston wrote:
> On 26/04/12 05:44, Walter Bright wrote:
>> A subtle but nasty problem - are default arguments part of the type, or
>> part of the declaration?
>>
>> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>>
>> Currently, they are both, which leads to the nasty behavior in the bug
>> report.
>>
>> The problem centers around name mangling. If two types mangle the same,
>> then they are the same type. But default arguments are not part of the
>> mangled string. Hence the schizophrenic behavior.
>>
>> But if we make default arguments solely a part of the function
>> declaration, then function pointers (and delegates) cannot have default
>> arguments. (And maybe this isn't a bad thing?)
>
> I think it is a mistake to allow default arguments in function pointers
> and delegates (it's OK for delegate literals, there you have the
> declaration).

The parenthesised part is in conflict with your other statement.

> I don't see how it can possibly work.
>
> If it's really a type, then given:
> void foo(int x = 2) {}
> void bar(int y = 3) {}
> then typeof(&foo) should be: void function (int __param0 = 2)
> I don't see how we could justify having those types and not using them.
>
> But then, if you have:
> auto p = &foo; // p has default parameter of 2
> p = &bar; // Should this work?
>
> I really don't think we want this.
>

We probably don't.

>
> As I vaguely remember someone saying about the bug report, it looks like
> an attempt to have a pathetic special case of currying syntax sugar
> built into the language.

I don't see how it relates to currying.

> But it isn't even as efficient as a library solution (if the
> construction of the default parameter is expensive, it will generate
> gobs of code every time the function parameter is called).

On 26/04/12 11:28, Timon Gehr wrote:
> On 04/26/2012 10:51 AM, Don Clugston wrote:
>> On 26/04/12 05:44, Walter Bright wrote:
>>> A subtle but nasty problem - are default arguments part of the type, or
>>> part of the declaration?
>>>
>>> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>>>
>>> Currently, they are both, which leads to the nasty behavior in the bug
>>> report.
>>>
>>> The problem centers around name mangling. If two types mangle the same,
>>> then they are the same type. But default arguments are not part of the
>>> mangled string. Hence the schizophrenic behavior.
>>>
>>> But if we make default arguments solely a part of the function
>>> declaration, then function pointers (and delegates) cannot have default
>>> arguments. (And maybe this isn't a bad thing?)
>>
>> I think it is a mistake to allow default arguments in function pointers
>> and delegates (it's OK for delegate literals, there you have the
>> declaration).
>
> The parenthesised part is in conflict with your other statement.

No it doesn't. A default argument is a delegate literal is part of the declaration, not part of the type.

On 26/04/12 11:21, Timon Gehr wrote:
> On 04/26/2012 09:54 AM, Walter Bright wrote:
>> On 4/26/2012 12:47 AM, Timon Gehr wrote:
>>> On 04/26/2012 05:44 AM, Walter Bright wrote:
>>>> A subtle but nasty problem - are default arguments part of the type, or
>>>> part of the declaration?
>>>>
>>>> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>>>>
>>>> Currently, they are both,
>>>
>>> That is how it should be.
>>>
>>>> which leads to the nasty behavior in the bug report.
>>>>
>>>
>>> It contributes, but it is not the main cause.
>>>
>>>> The problem centers around name mangling. If two types mangle the same,
>>>> then they are the same type.
>>>
>>> Then they are equal types.
>>
>> This is simply not tenable. What defines when they are "equal" types and
>> when they are "not equal"?
>
> This is a matter of terminology. For example, for 'equal' just exclude
> the default parameters from the comparison. For 'the same' include
> default parameters in the comparison. (therefore, 'the same' implies
> 'equal')

The language doesn't have the concepts of "same" and "equal" with respect to types. There is "equal" and "implicitly converts to", but that's not quite the same.

>>> The schizophrenic behavior occurs because the types cross-talk. Are
>>> mangled
>>> names kept unique in the compiler or what is the implementation issue
>>> exactly?
>>
>> It's a conceptual issue. When is one type the same as another, and when
>> is it not?
>>
>
> void function(int) is the same as void function(int) and both are equal
> void function(int=2) is not the same as void function(int=3), but both
> are equal.

The question was *when* are they same, not how you name them.

On 04/26/2012 11:46 AM, Don Clugston wrote:
> On 26/04/12 11:28, Timon Gehr wrote:
>> On 04/26/2012 10:51 AM, Don Clugston wrote:
>>> On 26/04/12 05:44, Walter Bright wrote:
>>>> A subtle but nasty problem - are default arguments part of the type, or
>>>> part of the declaration?
>>>>
>>>> See http://d.puremagic.com/issues/show_bug.cgi?id=3866
>>>>
>>>> Currently, they are both, which leads to the nasty behavior in the bug
>>>> report.
>>>>
>>>> The problem centers around name mangling. If two types mangle the same,
>>>> then they are the same type. But default arguments are not part of the
>>>> mangled string. Hence the schizophrenic behavior.
>>>>
>>>> But if we make default arguments solely a part of the function
>>>> declaration, then function pointers (and delegates) cannot have default
>>>> arguments. (And maybe this isn't a bad thing?)
>>>
>>> I think it is a mistake to allow default arguments in function pointers
>>> and delegates (it's OK for delegate literals, there you have the
>>> declaration).
>>
>> The parenthesised part is in conflict with your other statement.
>
> No it doesn't. A default argument is a delegate literal is part of the
> declaration, not part of the type.

If types cannot specify default arguments, then those will be thrown away right away, because what is later called is based on the type of the delegate and not on the implicit function declaration that has its address taken. What is the point of allowing it if it cannot be used?