View mode: basic / threaded / horizontal-split · Log in · Help
April 26, 2012
Re: What to do about default function arguments
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.
April 26, 2012
Re: What to do about default function arguments
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.)
April 26, 2012
Re: What to do about default function arguments
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?
April 26, 2012
Re: What to do about default function arguments
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).
April 26, 2012
Re: What to do about default function arguments
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
April 26, 2012
Re: What to do about default function arguments
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.
April 26, 2012
Re: What to do about default function arguments
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).
April 26, 2012
Re: What to do about default function arguments
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.
April 26, 2012
Re: What to do about default function arguments
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.
April 26, 2012
Re: What to do about default function arguments
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?
1 2 3 4 5
Top | Discussion index | About this forum | D home