www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Function pointers/delegates default args were stealth removed?

reply Manu <turkeyman gmail.com> writes:
--20cf3071ceb4fc194804c832b3c9
Content-Type: text/plain; charset=UTF-8

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

--20cf3071ceb4fc194804c832b3c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I just updated to 2.60 and found errors throughout my code where function p=
ointers default args no longer work.<div><u>Every single project</u> I&#39;=
ve written in D, 5 projects, don&#39;t work anymore, including my projects =
at work.</div>
<div><br></div><div>I found this discussion:=C2=A0<a href=3D"http://d.purem=
agic.com/issues/show_bug.cgi?id=3D3866">http://d.puremagic.com/issues/show_=
bug.cgi?id=3D3866</a></div><div>It seems the change was just decided and im=
plemented with basically no discussion or argument at all :/</div>
<div><br></div><div>My use cases are dynamic linkage, and cross-language in=
tegration.</div><div>I can&#39;t manually interact with DLL&#39;s containin=
g API&#39;s that expect to have default arguments if function pointers no l=
onger support them.</div>
<div>Also when receiving foreign language function pointers, they frequentl=
y need to have default args too.</div><div><br></div><div>I also integrate =
with many C style API&#39;s (rendering engines and the like), which involve=
 registration of various callbacks, and lots of those have default args too=
.</div>
<div><br></div><div>I find this particularly surprising, since I recently m=
otivated implementation of new traits which could parse default args from p=
arameter lists, and use that to generation function pointers in templates w=
hich auto-magically clone functions parameter lists verbatim, specifically =
including the default args...</div>

--20cf3071ceb4fc194804c832b3c9--
Aug 26 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
I don't think there's any cases where the change can't be worked 
around relatively easily. Correct me if I'm wrong.

I was also surprised to see this removed without mention, but 
after reading the bug, it seems like the correct decision. I 
don't like the idea of adding default arguments to types.
Aug 26 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.)
Aug 26 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.
Aug 26 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.
Aug 26 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 02:44 AM, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable?

Yes.
 Consider what you do with a function pointer - you pass it to someone
 else. That someone else gets it as a type, not a declaration.

If it is a template function, yes. But then you may as well pass the function pointer variable per alias, which is common. Otherwise someone else gets nothing but a parameter declaration.
 I.e. you lose the default argument information, since that is not attached to
the
 type.

I think most valid existing use cases would still be supported: int execFunctionPointer(int function(int = 2) fun){ return fun(); } auto dg = (int x, int y=2){ return x+y; } writeln(range.map!dg()); int function(int=3)[] funs; funs[0](); It is up to you if it is worth the effort, of course.
Aug 26 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2012 6:55 PM, Timon Gehr wrote:
 On 08/27/2012 02:44 AM, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable?

Yes.
 Consider what you do with a function pointer - you pass it to someone
 else. That someone else gets it as a type, not a declaration.

If it is a template function, yes. But then you may as well pass the function pointer variable per alias, which is common.

You pass the function declaration by alias, not the function pointer declaration. In which case you will get the default arguments.
 Otherwise someone else gets nothing but a parameter declaration.

 I.e. you lose the default argument information, since that is not attached to
the
 type.

I think most valid existing use cases would still be supported: int execFunctionPointer(int function(int = 2) fun){ return fun(); } auto dg = (int x, int y=2){ return x+y; } writeln(range.map!dg()); int function(int=3)[] funs; funs[0](); It is up to you if it is worth the effort, of course.

and it falls apart immediately once you try to transfer that function pointer anywhere.
Aug 26 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2012 8:49 PM, Chris Cain wrote:
 If I may, here's my suggestion on how everything could work (and I think should
 be doable) ... basically, it would be part of the type, but functions with the
 same parameters regardless of defaults would be implicitly convertible to one
 another:

What happens with the name mangling? What about overloading? template type deduction? type specialization? type equivalence? type covariance?
Aug 26 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2012 9:25 PM, Chris Cain wrote:
 On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:
 What happens with the name mangling? What about overloading? template type
 deduction? type specialization? type equivalence? type covariance?

Name mangling: Without knowing enough about compiler making, I'm not sure why it matters. I couldn't answer, sorry.

The mangled names have a 1:1 correspondence with types. A mangled name can, for example, be reversed into a type. If default args form part of the type, then they'll have to be mangled in, too. This causes a rather long list of substantial problems.
Aug 26 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2012 11:14 PM, Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

And then there's a list of other bugs that show up. Now you have two different types showing up as the same type (i.e. name) to the linker, and you've got weird collisions. Really, a type that is the same only different is a recipe for endless subtle and ugly problems. It's a nightmare.
Aug 27 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 10:48 AM, Piotr Duda wrote:
 2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/26/2012 11:14 PM, Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

And then there's a list of other bugs that show up. Now you have two different types showing up as the same type (i.e. name) to the linker, and you've got weird collisions.

For linker these types should be identical, so there shouldn't be any collisions, unless D handles default args fundamentally different than C++.

You said they should be part of the type for passing as template args: auto foo(T)(T dg){ return dg(); } // therefore assert(foo((int x=2)=>x)==2); // this instantiation assert(foo((int x=3)=>x)==3); // must differ from this one // ergo, they cannot have the same mangled symbol name!
Aug 27 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 01:16 PM, Artur Skawina wrote:
 On 08/27/12 12:54, Timon Gehr wrote:
 On 08/27/2012 10:48 AM, Piotr Duda wrote:
 2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/26/2012 11:14 PM, Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

And then there's a list of other bugs that show up. Now you have two different types showing up as the same type (i.e. name) to the linker, and you've got weird collisions.

For linker these types should be identical, so there shouldn't be any collisions, unless D handles default args fundamentally different than C++.

You said they should be part of the type for passing as template args: auto foo(T)(T dg){ return dg(); } // therefore assert(foo((int x=2)=>x)==2); // this instantiation assert(foo((int x=3)=>x)==3); // must differ from this one // ergo, they cannot have the same mangled symbol name!

Anonymous functions must be unique anyway. artur

What is the point?
Aug 27 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 27 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 08/27/12 13:46, Timon Gehr wrote:
 On 08/27/2012 01:16 PM, Artur Skawina wrote:
 On 08/27/12 12:54, Timon Gehr wrote:
 On 08/27/2012 10:48 AM, Piotr Duda wrote:
 2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/26/2012 11:14 PM, Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

And then there's a list of other bugs that show up. Now you have two different types showing up as the same type (i.e. name) to the linker, and you've got weird collisions.

For linker these types should be identical, so there shouldn't be any collisions, unless D handles default args fundamentally different than C++.

You said they should be part of the type for passing as template args: auto foo(T)(T dg){ return dg(); } // therefore assert(foo((int x=2)=>x)==2); // this instantiation assert(foo((int x=3)=>x)==3); // must differ from this one // ergo, they cannot have the same mangled symbol name!

Anonymous functions must be unique anyway.

What is the point?

I misunderstood, my fault, sorry. A template instantiation with a parameter containing a default argument must of course reflect that argument in the mangled name. Are there other cases where def-args can't be ignored? (not where they are just "lost", that is not a problem) artur
Aug 27 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 1:01 AM, Paulo Pinto wrote:
 For it sounds like constraining the language while keeping the C/C++ linker
 semantics, instead of using a D aware linker.

That's just one of the problems. And no, we can't go write our own linker on all platforms.
Aug 27 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 27 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 27 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 05:05 AM, Walter Bright wrote:
 On 8/26/2012 6:55 PM, Timon Gehr wrote:
 On 08/27/2012 02:44 AM, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable?

Yes.
 Consider what you do with a function pointer - you pass it to someone
 else. That someone else gets it as a type, not a declaration.

If it is a template function, yes. But then you may as well pass the function pointer variable per alias, which is common.

You pass the function declaration by alias, not the function pointer declaration. In which case you will get the default arguments.

The function declaration is not necessarily available and the pointer/delegate might not be a constant. This is the point of function pointers and delegates.
 Otherwise someone else gets nothing but a parameter declaration.

 I.e. you lose the default argument information, since that is not
 attached to the
 type.

I think most valid existing use cases would still be supported: int execFunctionPointer(int function(int = 2) fun){ return fun(); } auto dg = (int x, int y=2){ return x+y; } writeln(range.map!dg()); int function(int=3)[] funs; funs[0](); It is up to you if it is worth the effort, of course.

and it falls apart immediately once you try to transfer that function pointer anywhere.

No it does not. The examples people have posted where it breaks their code that I am aware of all would work with this scheme. What possible use case do you think would have to be supported by function pointer/delegate default arguments that cannot be supported without serious implementation problems?
Aug 27 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/28/2012 10:33 PM, Carl Sturtivant wrote:
 On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.

I think this is the right behavior too. Default arguments are IMHO just a compact way to write some simply related overloaded functions, e.g. thus: int sum(int x, int y = 1 ) { return x + y; } is just a compact way to write int sum(int x, int y) { return x + y; } int sum(int x) { return sum(x, 1); } ...

This interpretation is simply wrong. import std.stdio, std.c.stdlib; void* alloca20bytes(void* x = alloca(20)){ return x; } // your suggested transformation: /+void* alloca20bytes(void* x){ return x; } void* alloca20bytes(){ return alloca20bytes(alloca(20)); }+/ // would break the caller: void main(){ auto x = (cast(int*)alloca20bytes())[0..5]; x[] = 0; x[] += 2; writeln(x); }
Aug 28 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/26/2012 5:06 PM, Manu wrote:
 To be fair, it's not a very lively discussion. Spans 1 day, and only 3 people
 comment :)

If you want a lively discussion, start one up about what to name a keyword :-)
 Is that really an exhaustive set of options? It seems the other possibility
 (including the default arg in the equivalence test) wasn't really considered.

 The part that I don't understand is how the situation manifests in the first
place:

      auto foo = (int a = 1) { return a;};
      auto bar = (int a) { return a;};

      writeln(foo()); // writes '1'
      writeln(bar()); // writes '1' also!

 These are 2 distinct assignments. I would expect foo and bar /would/ each take
a
 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.
 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?
 I presume if I typed that code, there would be no problem?

 The discussion is obviously regarding implementation details...?

No.
     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?
     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.
     (Many uses of default arguments can be replaced with overloaded functions.)


 Can you suggest how? I can't think of a feasible approach.

I'd have to see what you were trying to do.
 You can't overload function pointers (multiple instances of variables with the
 same name). And by definition of a function /pointer/, I don't own the target
 function to overload it.
 I can't reasonably produce static wrappers either, unless the wrapper receives
 the function pointer I intend to call as an arg, which is super nasty.

 I can probably address the global/static ones via wrappers, but I don't love
 redundant function calls, it reduces debug build performance (see: all my rants
 about __forceinline), but that would only address the problem in a few
situations.
 This also undoes all that good work recently with the parameter list traits >_<


 As I see it, calling a function is possibly the single most important thing a
 programming language does. Flexibility in this regard is valuable. Default args
 in function pointers was a HUGE selling point of D to me, I've made extremely
 liberal use of this feature to great benefit throughout all my projects.
 But perhaps most importantly, this change has a huge impact on my code at
 work... I don't really want to imagine telling my boss that I need to rewrite
 the engine bindings and integration code. I'll look like the biggest dick this
 side of the Baltic :/

If you can show me a generic example of what you are trying to do, perhaps we can suggest a reasonable alternative.
Aug 26 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 1:08 AM, Manu wrote:
 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.

It was probably reduced from a larger scenario. Reduced bugs usually look pretty twisted.
 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).

Because the two types were considered to be the same, only different. ---------------------------------- Please post a canonical example of how you use this, so we can think of an alternative.
Aug 27 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 12:32 PM, Manu wrote:
 On 27 August 2012 11:28, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

     On 8/27/2012 1:08 AM, Manu wrote:


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


     Because the two types were considered to be the same, only different.


 And how was that a problem? They never interacted in the example, the
 assignments were totally separate, they shouldn't have been confused.
 Just speculating, but it just looks like the type was misrepresented
 when it was looked up from a map by name or something, and matched the
 wrong cached definition... or something along those lines.
 It looks like a bug exposed from implementation detail, I can't see
 anything in the bug report that shouldn't theoretically work fine.
 ...

+1.
Aug 27 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 02:48 PM, Robert Clipsham wrote:
 On Monday, 27 August 2012 at 10:32:28 UTC, Manu wrote:
 Because the two types were considered to be the same, only different.

And how was that a problem? They never interacted in the example, the assignments were totally separate, they shouldn't have been confused. Just speculating, but it just looks like the type was misrepresented when it was looked up from a map by name or something, and matched the wrong cached definition... or something along those lines. It looks like a bug exposed from implementation detail, I can't see anything in the bug report that shouldn't theoretically work fine.

I seem to recall I looked at this issue myself at one point. It goes something like: ---- auto foo = (int a = 1) { return a; }; auto bar = (int a) { return a; }; ---- int function(int) is mangled exactly the same as int function(int = 1) as default args aren't used for mangling. dmd does semantic analysis on the type of foo, which returns int function(int = 1), which is mangled as int function(int) and stored in dmd's hashmap of types (default args aren't mangled). When the semantic analysis of bar is done it checks the hashmap, sees that the type is already there (has the same name mangling) and does not repeat semantic analysis. If you switch the order of declarations then the opposite happens - the default arg is ignored.

If the compiler design *requires* equal types to be stored uniquely in a hash map, then the default args shouldn't be stored as part of the type in the AST. I assume it is rather inconvenient to fix, but certainly possible.
Aug 27 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 6:05 AM, Timon Gehr wrote:
 On 08/27/2012 02:48 PM, Robert Clipsham wrote:
 I seem to recall I looked at this issue myself at one point. It goes
 something like:
 ----
 auto foo = (int a = 1) { return a; };
 auto bar = (int a) { return a; };
 ----
 int function(int) is mangled exactly the same as int function(int = 1)
 as default args aren't used for mangling. dmd does semantic analysis on
 the type of foo, which returns int function(int = 1), which is mangled
 as int function(int) and stored in dmd's hashmap of types (default args
 aren't mangled). When the semantic analysis of bar is done it checks the
 hashmap, sees that the type is already there (has the same name
 mangling) and does not repeat semantic analysis. If you switch the order
 of declarations then the opposite happens - the default arg is ignored.


This is correct.
 If the compiler design *requires* equal types to be stored uniquely in
 a hash map, then the default args shouldn't be stored as part of the
 type in the AST. I assume it is rather inconvenient to fix, but
 certainly possible.

The language design requires a 1:1 mapping of mangling to types. Hence the compiler design to use the mangling as a hashmap key of types. The failure of that approach in this case points to a problem in the language design, not a bug in the compiler.
Aug 27 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-27 22:53, Walter Bright wrote:

 The language design requires a 1:1 mapping of mangling to types. Hence
 the compiler design to use the mangling as a hashmap key of types. The
 failure of that approach in this case points to a problem in the
 language design, not a bug in the compiler.

How does this then work when the body of the anonymous functions are different? How will they be identified? -- /Jacob Carlborg
Aug 27 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 11:53 PM, Jacob Carlborg wrote:
 How does this then work when the body of the anonymous functions are different?
 How will they be identified?

I don't know what you mean.
Aug 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-08-28 09:16, Walter Bright wrote:

 I don't know what you mean.

The original problem in the bug report looked like this: void main () { auto foo = (int a = 1) { return a; }; auto bar = (int a) { return a; }; writeln(foo()); writeln(bar()); } If I change one of the bodies of the anonymous functions to look like this: void main () { auto foo = (int a = 1) { return a; writeln("foo"); }; auto bar = (int a) { return a; }; writeln(foo()); writeln(bar()); } It behaves correctly and won't compile any more. -- /Jacob Carlborg
Aug 28 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-28 21:27, Robert Clipsham wrote:

 The body of the function has nothing to do with its type.

If I change the body of one of the functions the problem doesn't appear. -- /Jacob Carlborg
Aug 29 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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. Default arguments add no power to the language, you can quote me on that. 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. Thanks, Andrei
Aug 27 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 27 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 27 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Aug 27 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Aug 27 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 27 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 04:53 PM, 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

+1.
Aug 27 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2012 03:23 PM, kenji hara wrote:
 I think that the function type and its mangled name must not contain
 the default args, then I can agree with Walter at the point.

 But, I think the variables of function pointers and delegates still
 can have default args as a part of their declarations.
 (It will be a part of VarDeclaration, not a part of TypeFunction)
 In following case, the default arg looks like a part of the type, but
 actually is a part of the declaration of fp.

 void function(int n = 10) fp;
 pragma(msg, typeof(fp));  // should print void function(int), because
 default args are not a part of type.
 fp();  // I think this can be allowed, because fp can remember that
 the first parameter has the default argument.

 But, it seems to me there are some corner cases.

    // fp will *inherit* default args from its initializer, or not?
    auto fp = (int n = 10){}

I assume we'd like it to do that lest the user has to supply the type explicitly. It might lead to funny interactions though.
    // what is the actual default arg of fp?
    void function(int n = 10) fp1 = (int n = 20){}
    void function(int n) fp2 = (int n = 30){}
    void function(int n = 40) fp3 = (int n){}

The declared default arg overrides. I'd suggest to make it an error when it can be fixed by leaving out the default argument from a function literal occurring within the expression.
    // fp has ambiguous default arg, or has no default arg?
    auto fp1 = some_runtime_condition ? (int n = 10){} : (int n = 20){} ;
    // more complicated case, first defarg is same, then it will be *inherited*?
    auto fp2 = some_runtime_condition ? (int n = 10, string s =
 "hello"){} : (int n = 10, string s = "world"){} ;

I'd say, never attempt to combine default arguments in any way. It is not required to make it a hard error in all cases, because the error will occur when the user attempts to rely upon the non-existent default argument. By the argument from above, both of those should be in error.
    int function(int n = 10) fp;   // default arg of the first parameter is 10
    fp = (int n = 20){ return n; }  // function literal's default arg
 will be ignored (in my opinion), is this expected?

This specific expression should be in error, but it should probably be possible to do static int foo(int n=10){ return n; } int function(int = 20) fp = &foo; The reason why this should work is because adding a default argument should be as unlikely as possible to break existing code.
    // returning function pointer/delegate type can have default args?
    int delegate(int n = 10) foo(int x) { ... }

Seems easy enough to support for consistency.
 If we can take agreements each other about them, it may be supported.

I personally do not rely on them.
Aug 27 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 3:32 AM, Manu wrote:
 Well likewise, can you provide an example where, assuming that one bug were
 fixed, that the old approach actually caused a problem?
 The bug report shows a situation that has a clear presumed behaviour, and could
 surely have just been fixed.

Yes, I can make that example "work", but it would not make the general case work. It would just kick the can down the road, and I'd get more bug reports on those. I'll look at your example separately.
Aug 27 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 7:03 AM, foobar 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.

The annotations design discussed was about annotating declarations, not types.
Aug 27 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 3:32 AM, Manu wrote:
 Here's an advanced trick I use a lot since D doesn't extern to static C++
 methods (heavily simplified, this is way out of context):

 struct CPPClass
 {
      this()
      {
          // not my actual code, but effectively, write 'this' and the C++
method
 pointer into a delegate on initialisation [I wrap this process up using magic]
          void** pDelegate = cast(void**)&cppNonVirtualMethod;
          pDelegate[0] = this;
          pDelegate[1] = pCPPMethodPointer;
      }

      void delegate(int x = 0) cppNonVirtualMethod; // C++ methods often have
 default args

void delegate(int x) cppNonVirtualMethod; void callCppNonVirtualMethod(int x) { (*cppNonVirtualMethod)(x); } void callCppNonVirtualMethod() { callCppNonVirtualMethod(0); } With inlining on, the calls to the second overload should disappear, and you have the same code generated as you would for the default arg method. You could probably reduce the typing with some sort of mixin template, but this is the basic idea.
 private:
      // C++ method pointer received from foreign code during initialisation
      static void* pCPPMethodPointer;
 }

Aug 27 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 3:32 AM, Manu wrote:
 Almost all my API's are dynamically bound to foreign code, eg:

 extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1, ref
 const(Vector2) v2, ref const(Color) color = Color.white, BlendMode blendMode =
 BlendMode.Disabled ) fillTriangle2D;

These can all be handled in a straightforward (but admittedly wordy) method of wrapping the call to the function pointer in an overloaded function. I understand that you've probably got so many of these, it's drudgery to make the edits. Question: are the default values all of the form T.init? I.e. is Color.white == Color.init?
Aug 27 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 2:37 PM, Manu wrote:
 They can, see my prev post.

 It's less readable, less maintainable, more obscure to those reading the
code...
 the language had an awesome feature that addressed it directly.
 When mixins get involved, readability, syntax highlighting, and other basic IDE
 services all go out the window.

Ok, thanks, it helps immensely to see just what you're trying to do. Let me think about it some more.
Aug 27 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/27/2012 05:48 AM, Robert Clipsham wrote:

 I seem to recall I looked at this issue myself at one point. It goes
 something like:
 ----
 auto foo = (int a = 1) { return a; };
 auto bar = (int a) { return a; };
 ----
 int function(int) is mangled exactly the same as int function(int = 1)
 as default args aren't used for mangling. dmd does semantic analysis on
 the type of foo, which returns int function(int = 1), which is mangled
 as int function(int) and stored in dmd's hashmap of types (default args
 aren't mangled). When the semantic analysis of bar is done it checks the
 hashmap, sees that the type is already there (has the same name
 mangling) and does not repeat semantic analysis. If you switch the order
 of declarations then the opposite happens - the default arg is ignored.

I had opened a related bug recently: http://d.puremagic.com/issues/show_bug.cgi?id=8579 Ali
Aug 27 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
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? Because the relevant bug /was/ an implementation problem. I can see how changing the implementation is not really practical short-term, hence didn't comment on it at the time, but even the examples given as "unsound" were fine and could be well defined. Type equivalence != type identity. Default args shouldn't be part of the mangled names. But having them (defargs) for function pointers can be very useful, esp. for generics ("void f(int=42); auto fp = &f; fp();" could be made to work), it reduces the amount of glue required and increases productivity - one of D's main strengths. In the mean time hacks such as this one can probably help sometimes, like in the automatically-generated-bindings cases: void f(int one, string two, double three) { import std.stdio; writeln(one, two, three); } void main() { auto fp = CWDA!(typeof(&f), "1", "\"two\"", "3.14")(&f); fp(1, "two", 3.14); fp(1, "two"); fp(1); fp(); fp(four/4); } int four = 4; static struct _CWDA(C, DA...) { C ptr; alias ptr this; import std.traits; static if (DA.length==3) // POC; handling other cases left as an exercise ;) auto ref opCall(ParameterTypeTuple!C[0..$-3] a, ParameterTypeTuple!C[$-3] da1 = mixin(DA[$-3]), ParameterTypeTuple!C[$-2] da2 = mixin(DA[$-2]), ParameterTypeTuple!C[$-1] da3 = mixin(DA[$-1])) { return ptr(a, da1, da2, da3); } } auto CWDA(C, DA...)(C c) { _CWDA!(C, DA) p; p.ptr = c; return p; } but that's not really an acceptable solution, obviously. artur
Aug 27 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 08/27/12 12:54, Timon Gehr wrote:
 On 08/27/2012 10:48 AM, Piotr Duda wrote:
 2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/26/2012 11:14 PM, Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

And then there's a list of other bugs that show up. Now you have two different types showing up as the same type (i.e. name) to the linker, and you've got weird collisions.

For linker these types should be identical, so there shouldn't be any collisions, unless D handles default args fundamentally different than C++.

You said they should be part of the type for passing as template args: auto foo(T)(T dg){ return dg(); } // therefore assert(foo((int x=2)=>x)==2); // this instantiation assert(foo((int x=3)=>x)==3); // must differ from this one // ergo, they cannot have the same mangled symbol name!

Anonymous functions must be unique anyway. artur
Aug 27 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Aug 27 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 27/08/2012 23:08, Maxim Fomin a écrit :
 On Monday, 27 August 2012 at 20:29:15 UTC, deadalnix wrote:
 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.

I may be considered rude, but as I have understood from the first post Manu 1) decided to use a not fully designed language feature 2) used this feature in public API when working with DLLs (which is by itself a problematic area) 3) integrated this with other language in a a way that require substantial rewrite and possibly redesign 4) updated compiler which I consider a process of looking for problems and no excuse for making code-break change. Anyway, older version of compiler is available.

The amount of corrected bug make the option of using an older compiler unrealistic.
Aug 27 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-27 23:29, Manu wrote:

 Are you suggesting using DLL's is asking for trouble? Dynamic linkage is
 a fundamental part of software.

Yes, they don't properly work in D. -- /Jacob Carlborg
Aug 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 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.

I think Ada is doing what D does now, it doesn't accept default arguments for things like function pointers/delegates. Bye, bearophile
Aug 26 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3063dc03457ee204c834186a
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 01:41, Walter Bright <newshound2 digitalmars.com> wrote:

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

To be fair, it's not a very lively discussion. Spans 1 day, and only 3 people comment :) Is that really an exhaustive set of options? It seems the other possibility (including the default arg in the equivalence test) wasn't really considered. The part that I don't understand is how the situation manifests in the first place: auto foo = (int a = 1) { return a;}; auto bar = (int a) { return a;}; writeln(foo()); // writes '1' writeln(bar()); // writes '1' also! These are 2 distinct assignments. I would expect foo and bar *would* each take a 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. 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 = ...; I presume if I typed that code, there would be no problem? The discussion is obviously regarding implementation details...? 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'? 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... (Many uses of default arguments can be replaced with overloaded functions.)

Can you suggest how? I can't think of a feasible approach. You can't overload function pointers (multiple instances of variables with the same name). And by definition of a function *pointer*, I don't own the target function to overload it. I can't reasonably produce static wrappers either, unless the wrapper receives the function pointer I intend to call as an arg, which is super nasty. I can probably address the global/static ones via wrappers, but I don't love redundant function calls, it reduces debug build performance (see: all my rants about __forceinline), but that would only address the problem in a few situations. This also undoes all that good work recently with the parameter list traits
_<

As I see it, calling a function is possibly the single most important thing a programming language does. Flexibility in this regard is valuable. Default args in function pointers was a HUGE selling point of D to me, I've made extremely liberal use of this feature to great benefit throughout all my projects. But perhaps most importantly, this change has a huge impact on my code at work... I don't really want to imagine telling my boss that I need to rewrite the engine bindings and integration code. I'll look like the biggest dick this side of the Baltic :/ --20cf3063dc03457ee204c834186a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 01:41, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">On 8/26/2012 3:26 PM, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> I just updated to 2.60 and found errors throughout my code where function<b= r> pointers default args no longer work.<br></div> _Every single project_ I&#39;ve written in D, 5 projects, don&#39;t work an= ymore,<div class=3D"im"><br> including my projects at work.<br> <br> I found this discussion: <a href=3D"http://d.puremagic.com/issues/show_bug.= cgi?id=3D3866" target=3D"_blank">http://d.puremagic.com/issues/<u></u>show_= bug.cgi?id=3D3866</a><br> It seems the change was just decided and implemented with basically no<br> discussion or argument at all :/<br> <br> My use cases are dynamic linkage, and cross-language integration.<br> I can&#39;t manually interact with DLL&#39;s containing API&#39;s that expe= ct to have<br> default arguments if function pointers no longer support them.<br> Also when receiving foreign language function pointers, they frequently nee= d to<br> have default args too.<br> <br> I also integrate with many C style API&#39;s (rendering engines and the lik= e), which<br> involve registration of various callbacks, and lots of those have default a= rgs too.<br> <br> I find this particularly surprising, since I recently motivated implementat= ion<br> of new traits which could parse default args from parameter lists, and use = that<br> to generation function pointers in templates which auto-magically clone<br> functions parameter lists verbatim, specifically including the default args= ...<br> </div></blockquote> <br> 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 t= o make default arguments a characteristic of the declaration, not of the ty= pe.<br> </blockquote><div><br></div><div>To be fair, it&#39;s not a very lively dis= cussion. Spans 1 day, and only 3 people comment :)</div><div>Is that really= an exhaustive set of options? It seems the other possibility (including th= e default arg in the equivalence test) wasn&#39;t really considered.</div> <div><br></div><div>The part that I don&#39;t understand is how the situati= on manifests in the first place:</div><div><br></div><div><pre class=3D"bz_= comment_text" id=3D"comment_text_0" style=3D"font-size:medium;white-space:p= re-wrap;width:50em"> auto foo =3D (int a =3D 1) { return a;}; auto bar =3D (int a) { return a;}; </pre><pre class=3D"bz_comment_text" id=3D"comment_text_0" style=3D"font-si= ze:medium;white-space:pre-wrap;width:50em"> writeln(foo()); // writes &#= 39;1&#39; writeln(bar()); // writes &#39;1&#39; also!</pre></div><div>These are 2= distinct assignments. I would expect foo and bar <i>would</i> each take a = type that is technically equivalent, but foo&#39;s type would have the bonu= s default arg in its type record, just as a function pointer that were decl= ared explicitly.</div> <div>At what point does the compiler become confused? They never interact..= . The expected behaviour seems obvious to me, foo and bar should effectivel= y be:</div><div>=C2=A0 =C2=A0int function(int a =3D 1) foo =3D ..;</div><di= v>=C2=A0 =C2=A0int function(int a) bar =3D ...;</div> <div><br></div><div>I presume if I typed that code, there would be no probl= em?</div><div><br></div><div>The discussion is obviously regarding implemen= tation details...?</div><div><br></div><div><br></div><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> The trouble for function pointers, is that any default args would need to b= e part of the type, not the declaration.<br></blockquote><div><br></div><di= v>I thought they were part of the type already? I would have thought that&#= 39;s where they should be. Why is their new home more &#39;proper&#39;?</di= v> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I know it broke code (for many others, too), and I&#39;m very sorry about t= hat, but I don&#39;t see another way out.<br></blockquote><div><br></div><d= iv>It&#39;s a rather major breakage.=C2=A0I&#39;ve seen you reject far more= important changes solely on the grounds that they are a breaking change be= fore...</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Many uses of = default arguments can be replaced with overloaded functions.)<br></blockquo= te> <div><br></div><div>Can you suggest how? I can&#39;t think of a feasible ap= proach.</div><div><br></div><div>You can&#39;t overload function pointers= =C2=A0(multiple instances of variables with the same name). And by definiti= on of a function <i>pointer</i>, I don&#39;t own the target function to ove= rload it.</div> <div>I can&#39;t reasonably produce static wrappers either, unless the wrap= per receives the function pointer I intend to call as an arg, which is supe= r nasty.</div><div><br></div><div>I can probably address the global/static = ones via wrappers, but I don&#39;t love redundant function calls, it reduce= s debug build performance (see: all my rants about __forceinline), but that= would only address the problem in a few situations.</div> <div>This also undoes all that good work recently with the parameter list t= raits &gt;_&lt;</div><div><br></div><div><br></div><div>As I see it, callin= g a function is possibly the single most important thing a programming lang= uage does. Flexibility in this regard is valuable.=C2=A0Default args in fun= ction pointers was a HUGE selling point of D to me, I&#39;ve made extremely= liberal use of this feature to great benefit throughout all my projects.</= div> <div>But perhaps most importantly, this change has a huge impact on my code= at work... I don&#39;t really want to imagine telling my boss that I need = to rewrite the engine bindings and integration code. I&#39;ll look like the= biggest dick this side of the Baltic :/</div> </div> --20cf3063dc03457ee204c834186a--
Aug 26 2012
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
If I may, here's my suggestion on how everything could work (and 
I think should be doable) ... basically, it would be part of the 
type, but functions with the same parameters regardless of 
defaults would be implicitly convertible to one another:

------

void efpBad( int function(int) fun ) {
     return fun(); // Fails to compile, as expected
}

void efp1( int function(int) fun ) {
     return fun(1); // Compiles fine, works as expected
}

void efp1Def1( int function(int = 1) fun ) {
     return fun(); // Compiles fine, equivalent to fun(1) which 
should be expected
}


auto fn1p = (int x) { return x; };
auto fn1pDef = (int x = 2) { return x; };

auto fn2p = (int x, int y) { return x + y; };
auto fn2pDef = (int x, int y = 2) { return x + y; };


efp2(fn2p); // Fails to compile, obviously ... # of parameters 
don't match.
efp2(fn2pDef); // Fails to compile, # of parameters don't match 
(even though 1 has provided a "default")
efp2(fn1p); // Success ... returns 1 as expected
efp2(fn1pDef); // Ditto
efp3(fn1p); // Compiles ... implicitly convertible, returns 1 
(efp3 is providing the default above)
efp3(fn1pDef); // Successfully compiles, returns 1 ... NOT 5 
(because 1 is provided as the default in efp3 above)

// Implicitly convertible between variables
fn1p = fn1pDef; // Perfectly fine
fn1p(); // Fails to compile, must provide an argument!
fn1pDef = fn1p; // Again, fine. fn1pDef will allow the arg to 
have the default of 1 now.
fn1pDef(); // Succeeds, returns 1

fn1p = fn2pDef; // Fails to compile, as expected
fn1p = fn2p; // Nonsense, so it fails, of course

// IsExpressions
is(typeof(fn1p) == typeof(fn1pDef)); // False
is(typeof(fn1p) : typeof(fn1pDef));  // True
is(typeof(fn1pDef) : typeof(fn1p));  // True

I hope that was rigorous enough to show the behavior when passing 
around and such. I feel like this behavior would be acceptable 
for almost every use. I'm pretty sure this is how people were 
expecting it to behave before, anyway.

Is there a problem with it working this way? (Obviously, I'm no 
compiler expert)
Aug 26 2012
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:
 What happens with the name mangling? What about overloading? 
 template type deduction? type specialization? type equivalence? 
 type covariance?

Name mangling: Without knowing enough about compiler making, I'm not sure why it matters. I couldn't answer, sorry. Overloading: I'm making a guess, but do you mean something like this? void fn( int function(int) fp ) { ... } void fn( int function(int = 1) fp ) { ... } It should fail to compile. Type specialization: Templates? Bar!( int function(int) ) would have to be different than Bar!( int function(int = 1) ), I would think. Template type deduction: I don't really understand the question with this, actually. Type equivalence, type covariance: Like the is expressions I showed before? Or what do you mean? They should be implicitly convertible between each other. I'm just giving you the standpoint of a user of the language, not necessarily a compiler writer (I have an extremely basic understanding of compilers ... mostly, I just know lexing and parsing at the moment), so I'm having difficulty understanding what some of the problems with this is.
Aug 26 2012
prev sibling next sibling parent Piotr Duda <duda.piotr gmail.com> writes:
2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/26/2012 9:25 PM, Chris Cain wrote:
 On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:
 What happens with the name mangling? What about overloading? template
 type
 deduction? type specialization? type equivalence? type covariance?

Name mangling: Without knowing enough about compiler making, I'm not sur=


 why it
 matters. I couldn't answer, sorry.

The mangled names have a 1:1 correspondence with types. A mangled name ca=

 for example, be reversed into a type.

 If default args form part of the type, then they'll have to be mangled in=

 too. This causes a rather long list of substantial problems.

Default args should be part of types (for passing them as template args etc, implicity convertable if they differs only on defaults) but not mangled in (since mangling is revelant only for linking, where defaults doesn't matter). --=20 =E9=97=87=E3=81=AB=E9=9A=A0=E3=82=8C=E3=81=9F=E9=BB=92=E3=81=84=E5=8A=9B =E5=BC=B1=E3=81=84=E5=BF=83=E3=82=92=E6=93=8D=E3=82=8B
Aug 26 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51a7fe8f1b27e04c83aa0e2
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 07:52, Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/26/2012 9:25 PM, Chris Cain wrote:

 On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:

 What happens with the name mangling? What about overloading? template
 type
 deduction? type specialization? type equivalence? type covariance?

Name mangling: Without knowing enough about compiler making, I'm not sure why it matters. I couldn't answer, sorry.

The mangled names have a 1:1 correspondence with types. A mangled name can, for example, be reversed into a type. If default args form part of the type, then they'll have to be mangled in, too. This causes a rather long list of substantial problems.

This sounds like an implementation detail/dmd quirk is defining the language spec... I generally agree with the usage proposal above, it should be metadata that doesn't affect type equivalence (although I'd probably expect is(f1 == f2def) should be true rather than false). If that info needs to be mangled into the name to reproduce the type later, fine, is that a problem? Perhaps stick it at the end of the mangled name in a new metadata suffix that is truncated prior to any comparisons for equality? This actually rather relates to the attribute/annotation proposals/conversations we were having some time back. If this is addressed, then it may enable attributes too. --bcaec51a7fe8f1b27e04c83aa0e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 07:52, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">On 8/26/2012 9:25 PM, Chris Cain wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What happens with the name mangling? What about overloading? template type<= br> deduction? type specialization? type equivalence? type covariance?<br> </blockquote> <br> Name mangling: Without knowing enough about compiler making, I&#39;m not su= re why it<br> matters. I couldn&#39;t answer, sorry.<br> </blockquote> <br></div> The mangled names have a 1:1 correspondence with types. A mangled name can,= for example, be reversed into a type.<br> <br> If default args form part of the type, then they&#39;ll have to be mangled = in, too. This causes a rather long list of substantial problems.<br> </blockquote></div><br><div>This sounds like an implementation detail/dmd q= uirk is defining the language spec...</div><div>I generally agree with the = usage proposal above, it should be metadata that doesn&#39;t affect type eq= uivalence (although I&#39;d probably expect is(f1 =3D=3D f2def) should be t= rue rather than false).</div> <div>If that info needs to be mangled into the name to reproduce the type l= ater, fine, is that a problem? Perhaps stick it at the end of the mangled n= ame in a new metadata suffix that is truncated prior to any comparisons for= equality?</div> <div><br></div><div>This actually rather relates to the attribute/annotatio= n proposals/conversations we were having some time back. If this is address= ed, then it may enable attributes too.</div> --bcaec51a7fe8f1b27e04c83aa0e2--
Aug 27 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 27 August 2012 at 07:54:12 UTC, Manu wrote:
 On 27 August 2012 07:52, Walter Bright 
 <newshound2 digitalmars.com> wrote:

 On 8/26/2012 9:25 PM, Chris Cain wrote:

 On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright 
 wrote:

 What happens with the name mangling? What about overloading? 
 template
 type
 deduction? type specialization? type equivalence? type 
 covariance?

Name mangling: Without knowing enough about compiler making, I'm not sure why it matters. I couldn't answer, sorry.

The mangled names have a 1:1 correspondence with types. A mangled name can, for example, be reversed into a type. If default args form part of the type, then they'll have to be mangled in, too. This causes a rather long list of substantial problems.

This sounds like an implementation detail/dmd quirk is defining the language spec...

For it sounds like constraining the language while keeping the C/C++ linker semantics, instead of using a D aware linker. Not trolling, just trying to understand the design constraints. -- Paulo
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf307ca418a7bf7f04c83ad36c
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 03:51, Walter Bright <newshound2 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). --20cf307ca418a7bf7f04c83ad36c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 03:51, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">On 8/26/2012 5:06 PM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">type that is technically equivalent, but foo= &#39;s type would have the bonus default</blockquote></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> <div class=3D"im"> arg in its type record, just as a function pointer that were declared expli= citly.<br> </div></blockquote> <br> That&#39;s the way it used to work. The problem is, what are those types? A= re they the same types or not? You&#39;re saying sometimes they are the sam= e type, sometimes they are not. It&#39;s a mess.</blockquote><div><br> </div><div>They are always equivalent. The default args are more like metad= ata.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div= class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">At what point does the compiler become confu= sed? They never interact... The<br> expected behaviour seems obvious to me, foo and bar should effectively be:<= br> =C2=A0 =C2=A0 int function(int a =3D 1) foo =3D ..;<br> =C2=A0 =C2=A0 int function(int a) bar =3D ...;<br> </blockquote> <br></div> It seems obvious only in the trivial case. What if you passed foo to a func= tion? Now what type is it? What is the mangling for the type?</blockquote><= div><br></div><div>Well the function you pass foo to will define the type i= s receives.</div> <div>If it receives by template, then it&#39;ll receive the default args, i= f it defines the function pointer type it receives explicitly (or uses anot= her compatible definition), the default args may be lost (or different) in = the new instance across the function call.</div> <div><br></div><div>I don&#39;t see why it needs to be mangled in. The link= er doesn&#39;t care.</div><div><br></div><div><br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">=C2=A0 =C2=A0 The trouble = for function pointers, is that any default args would need to be<br> =C2=A0 =C2=A0 part of the type, not the declaration.<br> <br> <br></div><div class=3D"im"> I thought they were part of the type already? I would have thought that&#39= ;s where<br> they should be. Why is their new home more &#39;proper&#39;?<br> </div></blockquote> <br> Because are the types the same or not?<br></blockquote><div><br></div><div>= They&#39;re equivalent, but not identical; one has some metadata the other = doesn&#39;t have.</div><div><br></div><div><br></div><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">=C2=A0 =C2=A0 I know it br= oke code (for many others, too), and I&#39;m very sorry about that,<br> =C2=A0 =C2=A0 but I don&#39;t see another way out.<br> <br> <br></div><div class=3D"im"> It&#39;s a rather major breakage. I&#39;ve seen you reject far more importa= nt changes<br> solely on the grounds that they are a breaking change before...<br> </div></blockquote> <br> Unfortunately, it was already broken, as the bug report showed. It&#39;s a = matter of where the crack shows up.<br></blockquote><div><br></div><div>Doe= s the bug report actually demonstrate how it was causing anybody any proble= ms? It seemed a rather contrived scenario that just illustrated that there = was a bug.</div> <div>Also, I think it could be fixed so the scenario in the bug report work= ed as expected (I still don&#39;t understand why it did&#39;t work in the f= irst place).</div></div> --20cf307ca418a7bf7f04c83ad36c--
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7bf0f14ea2822104c83adbf1
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 11:01, Paulo Pinto <pjmlp progtools.org> wrote:

 On Monday, 27 August 2012 at 07:54:12 UTC, Manu wrote:

 This sounds like an implementation detail/dmd quirk is defining the
 language spec...

For it sounds like constraining the language while keeping the C/C++ linker semantics, instead of using a D aware linker.

I don't see how the linker enters into it. Default args are irrelevant to the linker. --047d7bf0f14ea2822104c83adbf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 11:01, Paulo Pinto <span dir= =3D"ltr">&lt;<a href=3D"mailto:pjmlp progtools.org" target=3D"_blank">pjmlp= progtools.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Monday, 27 August 2012 at 07:54:12 UTC, Manu wrote:<br=

eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><br></div><div class= =3D"im"> This sounds like an implementation detail/dmd quirk is defining the<br> language spec...<br> </div></blockquote> <br> For it sounds like constraining the language while keeping the C/C++ linker= semantics, instead of using a D aware linker.<br></blockquote><div><br></d= iv><div>I don&#39;t see how the linker enters into it. Default args are irr= elevant to the linker.</div> </div> --047d7bf0f14ea2822104c83adbf1--
Aug 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, August 27, 2012 08:14:41 Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

Default args are essentially copy-pasted at the call point. It makes no sense for them to be part of the type, and it makes no sense to use them with function pointers or function literals. - Jonathan M Davis
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
 The mangled names have a 1:1 correspondence with types. A 
 mangled name can, for example, be reversed into a type.

 If default args form part of the type, then they'll have to be 
 mangled in, too. This causes a rather long list of substantial 
 problems.

The following has other pervasive ramifications, to say the least. Worth thinking about IMHO nevertheless, even if to eventually say "no". So here's a completely different way that the effect of default arguments can be obtained without messing with the type system. Suppose a function pointer is always permitted be called with fewer actual arguments than parameters declared. I'm speculating uncritically here, so bear with me; this could be restricted to calling function pointers & delegate pointers, or with an avalanche of consequences permitted also for direct function calling where it will interact with the overloading rules, or ... there are many possible arrangements. So let's forge ahead for now with the basic idea for function pointers. Suppose a function pointer can be called with fewer actual arguments than the number of parameters in its declaration. Suppose that when such a call is made, the missing arguments will always be assigned the default initialization for their types (default default-arguments!). Now suppose that a language mechanism is provided so that code in the function body can determine how many actual arguments were supplied at the point of call. Now any function pointer can simulate other default arguments (non-default default arguments) by testing the actual number of arguments supplied and assigning defaults overtly to the remainder inside the function body. No need for new types: this is a run-time action. Now you can stamp on this with big logic boots, but let's see if I can escape from some of the trampling!
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3071ceb468ea5704c83b4170
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 11:12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 and it makes no sense to use them with function pointers or function
 literals.

If that were true, we wouldn't be having this discussion. --20cf3071ceb468ea5704c83b4170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 11:12, Jonathan M Davis <span = dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jm= davisProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><br> </div>and it makes no sense to use them with=C2=A0function pointers or func= tion literals.<br></blockquote><div><br></div><div>If that were true, we wo= uldn&#39;t be having this discussion.</div></div> --20cf3071ceb468ea5704c83b4170--
Aug 27 2012
prev sibling next sibling parent Piotr Duda <duda.piotr gmail.com> writes:
2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/26/2012 11:14 PM, Piotr Duda wrote:
 Default args should be part of types (for passing them as template
 args etc, implicity convertable if they differs only on defaults) but
 not mangled in (since mangling is revelant only for linking, where
 defaults doesn't matter).

And then there's a list of other bugs that show up. Now you have two different types showing up as the same type (i.e. name) to the linker, an=

 you've got weird collisions.

For linker these types should be identical, so there shouldn't be any collisions, unless D handles default args fundamentally different than C++. --=20 =E9=97=87=E3=81=AB=E9=9A=A0=E3=82=8C=E3=81=9F=E9=BB=92=E3=81=84=E5=8A=9B =E5=BC=B1=E3=81=84=E5=BF=83=E3=82=92=E6=93=8D=E3=82=8B
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
 Suppose a function pointer can be called with fewer actual 
 arguments than the number of parameters in its declaration. 
 Suppose that when such a call is made, the missing arguments 
 will always be assigned the default initialization for their 
 types (default default-arguments!). Now suppose that a language 
 mechanism is provided so that code in the function body can 
 determine how many actual arguments were supplied at the point 
 of call.

 Now any function pointer can simulate other default arguments 
 (non-default default arguments) by testing the actual number of 
 arguments supplied and assigning defaults overtly to the 
 remainder inside the function body. No need for new types: this 
 is a run-time action.

That's a great idea Carl! You mean something like this: int sum(int a, int b) { if( argc == 1 ) b = 1; //default for b if not supplied return a + b; } //... auto f = &sum; //... auto x = sum(y); //function pointer call, so fewer args permitted
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 08:26:15 UTC, Jonathan M Davis wrote:
 On Monday, August 27, 2012 08:14:41 Piotr Duda wrote:
 Default args should be part of types (for passing them as 
 template
 args etc, implicity convertable if they differs only on 
 defaults) but
 not mangled in (since mangling is revelant only for linking, 
 where
 defaults doesn't matter).

Default args are essentially copy-pasted at the call point. It makes no sense for them to be part of the type, and it makes no sense to use them with function pointers or function literals.

Agreed. So see my way of simulating these at run-time without adverse type consequences or any overhead for existing functions.
Aug 27 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 27 Aug 2012 11:57:45 +0200, Carl Sturtivant <sturtivant gmail.com>  
wrote:

 Suppose a function pointer can be called with fewer actual arguments  
 than the number of parameters in its declaration. Suppose that when  
 such a call is made, the missing arguments will always be assigned the  
 default initialization for their types (default default-arguments!).  
 Now suppose that a language mechanism is provided so that code in the  
 function body can determine how many actual arguments were supplied at  
 the point of call.

 Now any function pointer can simulate other default arguments  
 (non-default default arguments) by testing the actual number of  
 arguments supplied and assigning defaults overtly to the remainder  
 inside the function body. No need for new types: this is a run-time  
 action.

That's a great idea Carl!

You *do* know you're talking to yourself, right? -- Simen
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
 That's a great idea Carl! You mean something like this:

 int sum(int a, int b) {
   if( argc == 1 ) b = 1; //default for b if not supplied

   return a + b;
 }

 //...

 auto f = &sum;

 //...

 auto x = sum(y);  //function pointer call, so fewer args 
 permitted

oops! last line was supposed to be: auto x = f(y); //function pointer call, so fewer args permitted And for the record, 'argc' in the above is a name that has a similar status to 'this' and is equal to the number of arguments actually passed. Probably there's a better choice of name.
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 10:12:28 UTC, Simen Kjaeraas wrote:
 On Mon, 27 Aug 2012 11:57:45 +0200, Carl Sturtivant 
 <sturtivant gmail.com> wrote:

 Suppose a function pointer can be called with fewer actual 
 arguments than the number of parameters in its declaration. 
 Suppose that when such a call is made, the missing arguments 
 will always be assigned the default initialization for their 
 types (default default-arguments!). Now suppose that a 
 language mechanism is provided so that code in the function 
 body can determine how many actual arguments were supplied at 
 the point of call.

 Now any function pointer can simulate other default arguments 
 (non-default default arguments) by testing the actual number 
 of arguments supplied and assigning defaults overtly to the 
 remainder inside the function body. No need for new types: 
 this is a run-time action.

That's a great idea Carl!

You *do* know you're talking to yourself, right?

My alter ego, you mean? Someone has to talk to the poor guy.
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b339229f9eee004c83cd61d
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 11:28, Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/27/2012 1:08 AM, Manu wrote:

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

Because the two types were considered to be the same, only different.

And how was that a problem? They never interacted in the example, the assignments were totally separate, they shouldn't have been confused. Just speculating, but it just looks like the type was misrepresented when it was looked up from a map by name or something, and matched the wrong cached definition... or something along those lines. It looks like a bug exposed from implementation detail, I can't see anything in the bug report that shouldn't theoretically work fine. ------------------------------**----
 Please post a canonical example of how you use this, so we can think of an
 alternative.

Well likewise, can you provide an example where, assuming that one bug were fixed, that the old approach actually caused a problem? The bug report shows a situation that has a clear presumed behaviour, and could surely have just been fixed. Almost all my API's are dynamically bound to foreign code, eg: extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1, ref const(Vector2) v2, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled ) fillTriangle2D; extern(C) void function( ref const(Vector3) v0, ref const(Vector3) v1, ref const(Vector3) v2, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled ) fillTriangle; extern(C) void function( ref const(Vector2) vPosition, ref const(Vector2) vSizeref, ref BaseTexture texture, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled, TextureMode textureMode = TextureMode.AllChannels ) fillSprite; extern(C) void function( ref const(Vector2) vMin, ref const(Vector2) vMax, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled ) fillRectangle; extern(C) void function( ref const(Vector3) vMin, ref const(Vector3) vMax, ref const(Matrix4x3) mLocalToWorld = Matrix4x3.identity, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled ) fillBox; extern(C) void function( ref const(Vector3) vCenter, float fRadius, ref const(Matrix4x3) mLocalToWorld = Matrix4x3.identity, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled, int iTessellationX = 12, int iTessellationY = 8 ) fillSphere; extern(C) void function( float fLength, float fRadius, ref const(Matrix4x3) mLocalToWorld = Matrix4x3.identity, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled, int iTessellation = 10 ) fillCone; extern(C) void function( float fLength, float fRadius1, float fRadius2, ref const(Matrix4x3) mLocalToWorld = Matrix4x3.identity, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled, int iTessellation = 10 ) fillCylinder; extern(C) void function( ref const(Matrix4) mClipToWorld, ref const(Color) color = Color.white, BlendMode blendMode = BlendMode.Disabled ) fillFrustum; Functions in structs is common, default args are often convenient: struct MFMaterialInterface { extern (C) int function(void* pPlatformData) registerMaterial; extern (C) void function() unregisterMaterial; extern (C) void function(MFMaterial* pMaterial, MFMaterialCreateParams *pCreateParams = null) createInstance; extern (C) void function(MFMaterial* pMaterial) destroyInstance; extern (C) int function() getNumParams; extern (C) MFMaterialParameterInfo* function(int parameterIndex) getParameterInfo; extern (C) void function(MFMaterial* pMaterial, int parameterIndex, int argIndex, size_t value) setParameter; extern (C) size_t function(MFMaterial* pMaterial, int parameterIndex, int argIndex, void* pValue = null) getParameter; } extern (C) void function(const(char)* pName, const(MFMaterialInterface)* pInterface) MFMaterial_RegisterMaterialType; This isn't the best demonstration of this pattern, just a compact one. But function pointers in structs/classes is not unusual. Here's an advanced trick I use a lot since D doesn't extern to static C++ methods (heavily simplified, this is way out of context): struct CPPClass { this() { // not my actual code, but effectively, write 'this' and the C++ method pointer into a delegate on initialisation [I wrap this process up using magic] void** pDelegate = cast(void**)&cppNonVirtualMethod; pDelegate[0] = this; pDelegate[1] = pCPPMethodPointer; } void delegate(int x = 0) cppNonVirtualMethod; // C++ methods often have default args private: // C++ method pointer received from foreign code during initialisation static void* pCPPMethodPointer; } --047d7b339229f9eee004c83cd61d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 11:28, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">On 8/27/2012 1:08 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><br></blockquote></div><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Also, I think it could be fixed so the scenario in the bug report worked as= <br> expected (I still don&#39;t understand why it did&#39;t work in the first p= lace).<br> </blockquote> <br></div> Because the two types were considered to be the same, only different.<br></= blockquote><div><br></div><div>And how was that a problem? They never inter= acted in the example, the assignments were totally separate, they shouldn&#= 39;t have been confused.</div> <div>Just speculating, but it just looks like the type was misrepresented w= hen it was looked up from a map by name or something, and matched the wrong= cached definition... or something along those lines.</div><div>It looks li= ke a bug exposed from implementation detail, I can&#39;t see anything in th= e bug report that shouldn&#39;t theoretically work fine.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">-----------------------------= -<u></u>----<br> <br> Please post a canonical example of how you use this, so we can think of an = alternative.<br></blockquote><div><br></div><div><div>Well likewise, can yo= u provide an example where, assuming that one bug were fixed, that the old = approach actually caused a problem?</div> </div><div>The bug report shows a situation that has a clear presumed behav= iour, and could surely have just been fixed.</div><div><br></div><div><br><= /div><div><br></div><div><div>Almost all my API&#39;s are dynamically bound= to foreign code, eg:</div> <div><br></div><div>extern(C) void function( ref const(Vector2) v0, ref con= st(Vector2) v1, ref const(Vector2) v2, ref const(Color) color =3D Color.whi= te, BlendMode blendMode =3D BlendMode.Disabled ) fillTriangle2D;</div><div> extern(C) void function( ref const(Vector3) v0, ref const(Vector3) v1, ref = const(Vector3) v2, ref const(Color) color =3D Color.white, BlendMode blendM= ode =3D BlendMode.Disabled ) fillTriangle;</div><div>extern(C) void functio= n( ref const(Vector2) vPosition, ref const(Vector2) vSizeref, ref BaseTextu= re texture, ref const(Color) color =3D Color.white, BlendMode blendMode =3D= BlendMode.Disabled, TextureMode textureMode =3D TextureMode.AllChannels ) = fillSprite;</div> <div>extern(C) void function( ref const(Vector2) vMin, ref const(Vector2) v= Max, ref const(Color) color =3D Color.white, BlendMode blendMode =3D BlendM= ode.Disabled ) fillRectangle;</div><div>extern(C) void function( ref const(= Vector3) vMin, ref const(Vector3) vMax, ref const(Matrix4x3) mLocalToWorld = =3D Matrix4x3.identity, ref const(Color) color =3D Color.white, BlendMode b= lendMode =3D BlendMode.Disabled ) fillBox;</div> <div>extern(C) void function( ref const(Vector3) vCenter, float fRadius, re= f const(Matrix4x3) mLocalToWorld =3D Matrix4x3.identity, ref const(Color) c= olor =3D Color.white, BlendMode blendMode =3D BlendMode.Disabled, int iTess= ellationX =3D 12, int iTessellationY =3D 8 ) fillSphere;</div> <div>extern(C) void function( float fLength, float fRadius, ref const(Matri= x4x3) mLocalToWorld =3D Matrix4x3.identity, ref const(Color) color =3D Colo= r.white, BlendMode blendMode =3D BlendMode.Disabled, int iTessellation =3D = 10 ) fillCone;</div> <div>extern(C) void function( float fLength, float fRadius1, float fRadius2= , ref const(Matrix4x3) mLocalToWorld =3D Matrix4x3.identity, ref const(Colo= r) color =3D Color.white, BlendMode blendMode =3D BlendMode.Disabled, int i= Tessellation =3D 10 ) fillCylinder;</div> <div>extern(C) void function( ref const(Matrix4) mClipToWorld, ref const(Co= lor) color =3D Color.white, BlendMode blendMode =3D BlendMode.Disabled ) fi= llFrustum;</div></div><div><br></div><div><br></div><div>Functions in struc= ts is common, default args are often convenient:</div> <div><br></div><div><div>struct MFMaterialInterface</div><div>{</div><div><= span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>extern (C)= =C2=A0int =C2=A0 =C2=A0 =C2=A0 function(void* pPlatformData) registerMateri= al;</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </s= pan>extern (C)=C2=A0void =C2=A0 =C2=A0 =C2=A0function() unregisterMaterial;= </div> <div><br></div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre= "> </span>extern (C)=C2=A0void =C2=A0 =C2=A0 =C2=A0function(MFMaterial* pMa= terial, MFMaterialCreateParams *pCreateParams =3D null) createInstance;</di= v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>ext= ern (C)=C2=A0void =C2=A0 =C2=A0 =C2=A0function(MFMaterial* pMaterial) destr= oyInstance;</div> <div><br></div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre= "> </span>extern (C)=C2=A0int =C2=A0 =C2=A0 =C2=A0 function() getNumParams;= </div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span=
extern (C)=C2=A0MFMaterialParameterInfo* function(int parameterIndex) getP=

<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>exter= n (C)=C2=A0void =C2=A0 =C2=A0 =C2=A0function(MFMaterial* pMaterial, int par= ameterIndex, int argIndex, size_t value) setParameter;</div><div><span clas= s=3D"Apple-tab-span" style=3D"white-space:pre"> </span>extern (C)=C2=A0size= _t =C2=A0 =C2=A0function(MFMaterial* pMaterial, int parameterIndex, int arg= Index, void* pValue =3D null) getParameter;</div> <div>}</div><div><br></div><div>extern (C) void function(const(char)* pName= , const(MFMaterialInterface)* pInterface) MFMaterial_RegisterMaterialType;<= /div></div><div><br></div><div>This isn&#39;t the best demonstration of thi= s pattern, just a compact one. But function pointers in structs/classes is = not unusual.</div> <div><br></div><div><br></div><div><br></div><div>Here&#39;s an advanced tr= ick I use a lot since D doesn&#39;t extern to static C++ methods (heavily s= implified, this is way out of context):</div><div><br></div><div>struct CPP= Class</div> <div>{</div><div>=C2=A0 =C2=A0 this()</div><div>=C2=A0 =C2=A0 {</div><div>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 // not my actual code, but effectively, write &= #39;this&#39; and the C++ method pointer into a delegate on initialisation = [I wrap this process up using magic]</div> <div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 void** pDelegate =3D cast(void**)&amp;cppN= onVirtualMethod;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0pDelegate[0] = =3D this;</div><div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pDelegate[1] =3D=C2=A0= pCPPMethodPointer;</div></div><div>=C2=A0 =C2=A0 }</div><div><br></div><div=
=C2=A0 =C2=A0 void delegate(int x =3D 0) cppNonVirtualMethod; // C++ metho=

<div><br></div><div>private:</div><div>=C2=A0 =C2=A0 // C++ method pointer = received from foreign code during initialisation</div><div>=C2=A0 =C2=A0 st= atic void* pCPPMethodPointer;</div><div>}</div><div><br></div></div> --047d7b339229f9eee004c83cd61d--
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 08:39:01 UTC, Manu wrote:
 On 27 August 2012 11:12, Jonathan M Davis <jmdavisProg gmx.com> 
 wrote:

 and it makes no sense to use them with function pointers or 
 function
 literals.

If that were true, we wouldn't be having this discussion.

I think that we (at a minimum me and my alter ego) would find it helpful to acknowledge something along the following lines (in no particular order). 1. There is call for a default argument mechanism when calling function or delegate pointers. [Those who've used these extensively know they want them! Now we think about it, we want them too.] 2. The existing default argument mechanism which is to simply pad the call at compile time with the defaults read from the function definition is ill suited to function pointer calls. [Those who want sane compiler machinery know this.] 3. It's helpful to overtly acknowledge that function calling and function pointer calling are quite different. [They are already different in D because overloading is applied statically, just as default arguments have now become something only applied statically. A function pointer is to one function and overloading therefore doesn't exist.] 4. Function pointer calls being dynamical could perhaps have a dynamical mechanism to assign default arguments at run time, so as to go along with notions 1,2,3 above. [That way the function decides which arguments have been defaulted and assigns their default values at runtime, so the language merely needs a mechanism for the function body when run to find out which parameters it needs to assign defaults to i.e. how many arguments have actually been provided when the function pointer was called.] ---hence my earlier proposal. I'm feeling lonely ---please at least shoot it down!
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
 extern(C) void function( ref const(Vector2) v0, ref 
 const(Vector2) v1, ref const(Vector2) v2, ref const(Color) 
 color = Color.white, BlendMode blendMode = BlendMode.Disabled ) 
 fillTriangle2D;

If function pointers could be called with fewer than the prototypical number of arguments, and the remaining arguments be always initialized to their .init defaults, you could perhaps make this sort of thing work without the default argument values by using struct defaults. How would that be deficient?
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args 
 would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.

This problem goes away if the defaults are always the same: the .init defaults, and if function pointers (but not functions) can be called with fewer arguments than there are parameters in their definition. When the call is made, the remaining argument can be provided using the standard .init defaults. And because the standard .init defaults can be manipulated via defining new types for the parameters, it becomes the parameter's types that the defaults are found from, and defaults do not need to be encoded in the types of function pointers. And if you don't like all function pointers getting this treatment, then it could be extended only to those that are given a qualification indicating so: one more binary bit added to mangling of its type. This mechanism could be made to work equally well with extern(C) etc. functions.
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf307f3bb2dab7d604c83e43bd
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 14:08, Carl Sturtivant <sturtivant gmail.com> wrote:

 extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1,
 ref const(Vector2) v2, ref const(Color) color = Color.white, BlendMode
 blendMode = BlendMode.Disabled ) fillTriangle2D;

If function pointers could be called with fewer than the prototypical number of arguments, and the remaining arguments be always initialized to their .init defaults, you could perhaps make this sort of thing work without the default argument values by using struct defaults. How would that be deficient?

... no. Color does not .init == Color.white. You're suggesting I define a new type, obscuring the API, every time I want a non-.init default arg? Also, I think it's correct that functions shouldn't be callable without explicit parameters. Default args are carefully selected, and they are always opt-in. 'v2' in this case shouldn't be allowed to default to [ NaN, NaN ] if I omit it. --20cf307f3bb2dab7d604c83e43bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div>On 27 August 2012 14:08, Carl Sturtivant <span dir=3D"ltr">&lt;<a href= =3D"mailto:sturtivant gmail.com" target=3D"_blank">sturtivant gmail.com</a>= &gt;</span> wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1, ref = const(Vector2) v2, ref const(Color) color =3D Color.white, BlendMode blendM= ode =3D BlendMode.Disabled ) fillTriangle2D;<br> </blockquote> <br></div> If function pointers could be called with fewer than the prototypical numbe= r of arguments, and the remaining arguments be always initialized to their = .init defaults, you could perhaps make this sort of thing work without the = default argument values by using struct defaults.<br> <br> How would that be deficient?<br></blockquote><div></div></div><br><div>... = no.</div><div>Color does not .init =3D=3D Color.white. You&#39;re suggestin= g I define a new type, obscuring the API, every time I want a non-.init def= ault arg?</div> <div>Also, I think it&#39;s correct that functions shouldn&#39;t be callabl= e without explicit parameters. Default args are carefully selected, and the= y are always opt-in.</div><div>&#39;v2&#39; in this case shouldn&#39;t be a= llowed to default to [ NaN, NaN ] if I omit it.</div> --20cf307f3bb2dab7d604c83e43bd--
Aug 27 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, August 27, 2012 11:38:52 Manu wrote:
 On 27 August 2012 11:12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 and it makes no sense to use them with function pointers or function
 literals.

If that were true, we wouldn't be having this discussion.

You can't possibly really be using these functions with default arguments unless you're not really using them like function pointers, otherwise you wouldn't have been using the default arguments in the first place. Sure, you could have something like auto func = (string a = "hello") { return a; } and then call it with one argument or no argument, but that's only because the function is completely local, and you could just as easily do string func(string a = "hello") { return a; } and get the same thing. As soon as you've really used it as a function pointer rather than a local function, you've lost the default argument. Default arguments just do not make sense with function pointers, because they don't follow the function pointer, because it's a _pointer_ and has no knowledge of what it's pointing to. It's only at the declaration point of the function that the default argument exists, and that has _nothing_ to do with the function pointer. You might as well ask a reference of type Object what the arguments used to construct the derived class that it actually refers to were as expect a function pointer to have any clue about default arguments to the function that it points to. - Jonathan M Davis
Aug 27 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1446.1346070222.31962.digitalmars-d puremagic.com...
 Default arguments just do not make sense with function pointers, because 
 they
 don't follow the function pointer, because it's a _pointer_ and has no
 knowledge of what it's pointing to. It's only at the declaration point of 
 the
 function that the default argument exists, and that has _nothing_ to do 
 with
 the function pointer. You might as well ask a reference of type Object 
 what
 the arguments used to construct the derived class that it actually refers 
 to
 were as expect a function pointer to have any clue about default arguments 
 to
 the function that it points to.

 - Jonathan M Davis

Yes, this. I looked into fixing issue 3866 earlier this year, and Kenji's list sounds very familiar. It comes down to - function pointers are not function declarations and therefore can't do everything function declarations do, such as overloading and default arguments. This is the price of being able to reassign them. Yes it is possible to make them work the way Manu has been using them, but the solution is messy and I seriously doubt it's worth it. I agree with everything Andrei has said about this. I don't consider putting default arguments back in the type a valid approach because of the reason above, so that leaves giving function pointer variables the ability to have default arguments. This seems to me like a really dumb corner case with the same problems.
Aug 28 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/28/12 8:23 AM, Manu wrote:
 Well that's painful for a number of reasons..
 Other than the fact that I need to rewrite a bunch of code,

Walter and Kenji think breaking meaningful existing code is an overriding concern, and I ended up agreeing with them. They will look into a solution that keeps your working code working. This change of wind may as well turn a new page in the history of D :o). Andrei
Aug 28 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/6/12 11:15 AM, kenji hara wrote:
 OK. I have finished working to implement it as a new pull request.
 https://github.com/D-Programming-Language/dmd/pull/1102

 It contains several test suites that indicate which case is supported or not.
 https://github.com/D-Programming-Language/dmd/pull/1102/files#L6R1

 Regards.

 Kenji Hara

Thank you very much! Andrei
Sep 06 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf307f3bb23a979404c83e9acf
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 13:54, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Monday, August 27, 2012 11:38:52 Manu wrote:
 On 27 August 2012 11:12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 and it makes no sense to use them with function pointers or function
 literals.

If that were true, we wouldn't be having this discussion.

You can't possibly really be using these functions with default arguments unless you're not really using them like function pointers, otherwise you wouldn't have been using the default arguments in the first place.

How do I use a function pointer 'like a function pointer' by your reasoning? Is dynamic linkage not a valid use of function pointers? It's possibly the *most* common use. Shared code is not exactly uncommon, just that it's often automated with compiler sugar these days. Manually binding dynamic code has become rare, but it's still valid. Default arguments just do not make sense with function pointers, because
 they
 don't follow the function pointer, because it's a _pointer_ and has no
 knowledge of what it's pointing to. It's only at the declaration point of
 the
 function that the default argument exists, and that has _nothing_ to do
 with
 the function pointer.

Clearly, since it's a function pointer, I don't own the function its self, or I'd just call that directly. However, as you say, at the declaration point of the function pointer, I can likewise inform the compiler of the default args. If the default args were worked into the variable declaration, that might work just as well as if it were in the type. I don't really care so much HOW it works, only that it does. I think 99% of my cases would be addressed by the def args living in the variable declaration. You might as well ask a reference of type Object what
 the arguments used to construct the derived class that it actually refers
 to
 were as expect a function pointer to have any clue about default arguments
 to
 the function that it points to.

I agree, in principle, but I've still lost a thoroughly useful feature. Move it perhaps (to the declaration?), but don't *re-*move it (cough). --20cf307f3bb23a979404c83e9acf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 13:54, Jonathan M Davis <span = dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jm= davisProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Monday, August 27, 2012 11:38:52= Manu wrote:<br> &gt; On 27 August 2012 11:12, Jonathan M Davis &lt;<a href=3D"mailto:jmdavi= sProg gmx.com">jmdavisProg gmx.com</a>&gt; wrote:<br> &gt; &gt; and it makes no sense to use them with function pointers or funct= ion<br> &gt; &gt; literals.<br> &gt;<br> &gt; If that were true, we wouldn&#39;t be having this discussion.<br> <br> </div></div>You can&#39;t possibly really be using these functions with def= ault arguments<br> unless you&#39;re not really using them like function pointers, otherwise y= ou<br> wouldn&#39;t have been using the default arguments in the first place.</blo= ckquote><div><br></div><div>How do I use a function pointer &#39;like a fun= ction pointer&#39; by your reasoning?</div><div>Is dynamic linkage not a va= lid use of function pointers?</div> <div>It&#39;s possibly the <u>most</u> common use. Shared code is not exact= ly uncommon, just that it&#39;s often automated with compiler sugar these d= ays.</div><div>Manually binding dynamic code has become rare, but it&#39;s = still valid.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Default arguments just do not make sense with function pointers, because th= ey<br> don&#39;t follow the function pointer, because it&#39;s a _pointer_ and has= no<br> knowledge of what it&#39;s pointing to. It&#39;s only at the declaration po= int of the<br> function that the default argument exists, and that has _nothing_ to do wit= h<br> the function pointer.</blockquote><div><br></div><div>Clearly, since it&#39= ;s a function pointer, I don&#39;t own the function its self, or I&#39;d ju= st call that directly.</div><div>However, as you say, at the declaration po= int of the function pointer, I can likewise inform the compiler of the defa= ult args.</div> <div>If the default args were worked into the variable declaration, that mi= ght work just as well as if it were in the type.</div><div><br></div><div>I= don&#39;t really care so much HOW it works, only that it does. I think 99%= of my cases would be addressed by the def args living in the variable decl= aration.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You might as w= ell ask a reference of type Object what<br> the arguments used to construct the derived class that it actually refers t= o<br> were as expect a function pointer to have any clue about default arguments = to<br> the function that it points to.<br></blockquote><div><br></div><div>I agree= , in principle, but I&#39;ve still lost a thoroughly useful feature. Move i= t perhaps (to the declaration?), but don&#39;t <i>re-</i>move it (cough).</= div> </div> --20cf307f3bb23a979404c83e9acf--
Aug 27 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2012 5:38 AM, Manu wrote:
 I don't really care so much HOW it works, only that it does. I think 99% of my
 cases would be addressed by the def args living in the variable declaration.

Can you please post a canonical 99% use case that you use? I cannot suggest an alternative otherwise. I need to understand what coding problem you have been solving with default args. For example, the basic use case of default args is just a shorthand for doing function overloads: int foo(int a = 5) { ... } becomes: int foo(int a) { ... } int foo() { return foo(5); } Many use cases involving templates can be resolved by using alias template parameters. But I don't know what your use cases are.
Aug 27 2012
prev sibling next sibling parent "Robert Clipsham" <robert octarineparrot.com> writes:
On Monday, 27 August 2012 at 10:32:28 UTC, Manu wrote:
 Because the two types were considered to be the same, only 
 different.

And how was that a problem? They never interacted in the example, the assignments were totally separate, they shouldn't have been confused. Just speculating, but it just looks like the type was misrepresented when it was looked up from a map by name or something, and matched the wrong cached definition... or something along those lines. It looks like a bug exposed from implementation detail, I can't see anything in the bug report that shouldn't theoretically work fine.

I seem to recall I looked at this issue myself at one point. It goes something like: ---- auto foo = (int a = 1) { return a; }; auto bar = (int a) { return a; }; ---- int function(int) is mangled exactly the same as int function(int = 1) as default args aren't used for mangling. dmd does semantic analysis on the type of foo, which returns int function(int = 1), which is mangled as int function(int) and stored in dmd's hashmap of types (default args aren't mangled). When the semantic analysis of bar is done it checks the hashmap, sees that the type is already there (has the same name mangling) and does not repeat semantic analysis. If you switch the order of declarations then the opposite happens - the default arg is ignored.
Aug 27 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 12:14:30 UTC, Manu wrote:
 On 27 August 2012 14:08, Carl Sturtivant <sturtivant gmail.com> 
 wrote:

 extern(C) void function( ref const(Vector2) v0, ref 
 const(Vector2) v1,
 ref const(Vector2) v2, ref const(Color) color = Color.white, 
 BlendMode
 blendMode = BlendMode.Disabled ) fillTriangle2D;

If function pointers could be called with fewer than the prototypical number of arguments, and the remaining arguments be always initialized to their .init defaults, you could perhaps make this sort of thing work without the default argument values by using struct defaults. How would that be deficient?

... no. Color does not .init == Color.white. You're suggesting I define a new type, obscuring the API, every time I want a non-.init default arg? Also, I think it's correct that functions shouldn't be callable without explicit parameters. Default args are carefully selected, and they are always opt-in. 'v2' in this case shouldn't be allowed to default to [ NaN, NaN ] if I omit it.

Yes, I am suggesting that to get the default you want you define a new (free at runtime) type. You need the D declaration of whichever C struct anyway, so this is that declaration with a default added. In a more complex situation aliasing can be used. For e.g. doubles, you can play a suitable struct game for once and for all, and use it repeatedly inside the D version of C structs. And I am suggesting the language definition be changed to allow calls of function pointers be made with some trailing arguments omitted. If default arguments for function pointers are not available, except for the default defaults (.init), then what of this proposal?
Aug 27 2012
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
I think that the function type and its mangled name must not contain
the default args, then I can agree with Walter at the point.

But, I think the variables of function pointers and delegates still
can have default args as a part of their declarations.
(It will be a part of VarDeclaration, not a part of TypeFunction)
In following case, the default arg looks like a part of the type, but
actually is a part of the declaration of fp.

void function(int n = 10) fp;
pragma(msg, typeof(fp));  // should print void function(int), because
default args are not a part of type.
fp();  // I think this can be allowed, because fp can remember that
the first parameter has the default argument.

But, it seems to me there are some corner cases.

  // fp will *inherit* default args from its initializer, or not?
  auto fp = (int n = 10){}

  // what is the actual default arg of fp?
  void function(int n = 10) fp1 = (int n = 20){}
  void function(int n) fp2 = (int n = 30){}
  void function(int n = 40) fp3 = (int n){}

  // fp has ambiguous default arg, or has no default arg?
  auto fp1 = some_runtime_condition ? (int n = 10){} : (int n = 20){} ;
  // more complicated case, first defarg is same, then it will be *inherited*?
  auto fp2 = some_runtime_condition ? (int n = 10, string s =
"hello"){} : (int n = 10, string s = "world"){} ;

  int function(int n = 10) fp;   // default arg of the first parameter is 10
  fp = (int n = 20){ return n; }  // function literal's default arg
will be ignored (in my opinion), is this expected?

  // returning function pointer/delegate type can have default args?
  int delegate(int n = 10) foo(int x) { ... }

If we can take agreements each other about them, it may be supported.

Kenji Hara

2012/8/27 Walter Bright <newshound2 digitalmars.com>:
 On 8/27/2012 1:08 AM, Manu wrote:
 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.

It was probably reduced from a larger scenario. Reduced bugs usually look pretty twisted.
 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).

Because the two types were considered to be the same, only different. ---------------------------------- Please post a canonical example of how you use this, so we can think of an alternative.

Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b33922989d5b404c83f86f9
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 15:48, Robert Clipsham <robert octarineparrot.com> wrote:

 I seem to recall I looked at this issue myself at one point. It goes
 something like:
 ----

 auto foo = (int a = 1) { return a; };
 auto bar = (int a) { return a; };
 ----
 int function(int) is mangled exactly the same as int function(int = 1) as
 default args aren't used for mangling. dmd does semantic analysis on the
 type of foo, which returns int function(int = 1), which is mangled as int
 function(int) and stored in dmd's hashmap of types (default args aren't
 mangled). When the semantic analysis of bar is done it checks the hashmap,
 sees that the type is already there (has the same name mangling) and does
 not repeat semantic analysis. If you switch the order of declarations then
 the opposite happens - the default arg is ignored.

Cached in a hashmap! precisely what I suspected (without knowing anything about it) ;) That explains why Walter keeps going on about the name mangling. It's all clear. --047d7b33922989d5b404c83f86f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 15:48, Robert Clipsham <span d= ir=3D"ltr">&lt;<a href=3D"mailto:robert octarineparrot.com" target=3D"_blan= k">robert octarineparrot.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">I seem to recall I looked at this issue myself at one poi= nt. It goes something like:</div> ----<div class=3D"im"><br> auto foo =3D (int a =3D 1) { return a; };<br> auto bar =3D (int a) { return a; };<br></div> ----<br> int function(int) is mangled exactly the same as int function(int =3D 1) as= default args aren&#39;t used for mangling. dmd does semantic analysis on t= he type of foo, which returns int function(int =3D 1), which is mangled as = int function(int) and stored in dmd&#39;s hashmap of types (default args ar= en&#39;t mangled). When the semantic analysis of bar is done it checks the = hashmap, sees that the type is already there (has the same name mangling) a= nd does not repeat semantic analysis. If you switch the order of declaratio= ns then the opposite happens - the default arg is ignored.<br> </blockquote></div><br><div>Cached in a hashmap! precisely what I suspected= (without knowing anything about it) ;)</div><div>That explains why Walter = keeps going on about the name mangling. It&#39;s all clear.</div> --047d7b33922989d5b404c83f86f9--
Aug 27 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 27 August 2012 at 13:44:43 UTC, Manu wrote:
 On 27 August 2012 15:48, Robert Clipsham 
 <robert octarineparrot.com> wrote:

 I seem to recall I looked at this issue myself at one point. 
 It goes
 something like:
 ----

 auto foo = (int a = 1) { return a; };
 auto bar = (int a) { return a; };
 ----
 int function(int) is mangled exactly the same as int 
 function(int = 1) as
 default args aren't used for mangling. dmd does semantic 
 analysis on the
 type of foo, which returns int function(int = 1), which is 
 mangled as int
 function(int) and stored in dmd's hashmap of types (default 
 args aren't
 mangled). When the semantic analysis of bar is done it checks 
 the hashmap,
 sees that the type is already there (has the same name 
 mangling) and does
 not repeat semantic analysis. If you switch the order of 
 declarations then
 the opposite happens - the default arg is ignored.

Cached in a hashmap! precisely what I suspected (without knowing anything about it) ;) That explains why Walter keeps going on about the name mangling. It's all clear.

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.
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51a7fe8e6e61b04c83fcaa1
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 16:23, kenji hara <k.hara.pg gmail.com> wrote:

 I think that the function type and its mangled name must not contain
 the default args, then I can agree with Walter at the point.

 But, I think the variables of function pointers and delegates still
 can have default args as a part of their declarations.
 (It will be a part of VarDeclaration, not a part of TypeFunction)
 In following case, the default arg looks like a part of the type, but
 actually is a part of the declaration of fp.

 void function(int n = 10) fp;
 pragma(msg, typeof(fp));  // should print void function(int), because
 default args are not a part of type.
 fp();  // I think this can be allowed, because fp can remember that
 the first parameter has the default argument.

 But, it seems to me there are some corner cases.

   // fp will *inherit* default args from its initializer, or not?
   auto fp = (int n = 10){}

I'd say, will. // what is the actual default arg of fp?
   void function(int n = 10) fp1 = (int n = 20){}

   void function(int n = 40) fp3 = (int n){}

The declaration (on the left) is correct in all cases. It was explicitly stated when defining the variable. // fp has ambiguous default arg, or has no default arg?
   auto fp1 = some_runtime_condition ? (int n = 10){} : (int n = 20){} ;

Finally, a REAL conundrum! :) .. Not sure what to tell you... Error? Warning, and remove the default arg since there's a disagreement?
   // more complicated case, first defarg is same, then it will be
 *inherited*?
   auto fp2 = some_runtime_condition ? (int n = 10, string s =
 "hello"){} : (int n = 10, string s = "world"){} ;

Same problem as above. I'd say hard error, since this is a) extremely unlikely! And b) it's obvious there's no 'correct' conclusion anyway. The user writing that code clearly imagines that D is a dynamic language, and doesn't properly understand the nature of a compiled language. int function(int n = 10) fp; // default arg of the first parameter is 10
   fp = (int n = 20){ return n; }  // function literal's default arg
 will be ignored (in my opinion), is this expected?

Agree, the variable was already defined by the users explicit request. // returning function pointer/delegate type can have default args?
   int delegate(int n = 10) foo(int x) { ... }

Sure, why not? If the recipient is auto, then it should inherit those properties. If we can take agreements each other about them, it may be supported.

+1 for Kenji :) --bcaec51a7fe8e6e61b04c83fcaa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 16:23, kenji hara <span dir=3D= "ltr">&lt;<a href=3D"mailto:k.hara.pg gmail.com" target=3D"_blank">k.hara.p= g gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I think that the function type and its mangled name must not contain<br> the default args, then I can agree with Walter at the point.<br> <br> But, I think the variables of function pointers and delegates still<br> can have default args as a part of their declarations.<br> (It will be a part of VarDeclaration, not a part of TypeFunction)<br> In following case, the default arg looks like a part of the type, but<br> actually is a part of the declaration of fp.<br> <br> void function(int n =3D 10) fp;<br> pragma(msg, typeof(fp)); =C2=A0// should print void function(int), because<= br> default args are not a part of type.<br> fp(); =C2=A0// I think this can be allowed, because fp can remember that<br=

<br> But, it seems to me there are some corner cases.<br> <br> =C2=A0 // fp will *inherit* default args from its initializer, or not?<br> =C2=A0 auto fp =3D (int n =3D 10){}<br></blockquote><div><br></div><div>I&#= 39;d say, will.</div><div><br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=C2=A0 /= / what is the actual default arg of fp?<br> =C2=A0 void function(int n =3D 10) fp1 =3D (int n =3D 20){}<br></blockquote=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

=3D 30){}<br> =C2=A0 void function(int n =3D 40) fp3 =3D (int n){}<br></blockquote><div><= br></div><div>The declaration (on the left) is correct in all cases. It was= explicitly stated when defining the variable.</div><div><br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"> =C2=A0 // fp has ambiguous default arg, or has no default arg?<br> =C2=A0 auto fp1 =3D some_runtime_condition ? (int n =3D 10){} : (int n =3D = 20){} ;<br></blockquote><div><br></div><div>Finally, a REAL=C2=A0conundrum!= :) .. Not sure what to tell you... Error? Warning, and remove the default = arg since there&#39;s a disagreement?</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> =C2=A0 // more complicated case, first defarg is same, then it will be *inh= erited*?<br> =C2=A0 auto fp2 =3D some_runtime_condition ? (int n =3D 10, string s =3D<br=

r></blockquote><div><br></div><div>Same problem as above. I&#39;d say hard = error, since this is a) extremely unlikely! And b) it&#39;s obvious there&#= 39;s no &#39;correct&#39; conclusion anyway.</div> <div>The user writing that code clearly imagines that D is a dynamic langua= ge, and doesn&#39;t properly understand the nature of a compiled language.<= /div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> =C2=A0 int function(int n =3D 10) fp; =C2=A0 // default arg of the first pa= rameter is 10<br> =C2=A0 fp =3D (int n =3D 20){ return n; } =C2=A0// function literal&#39;s d= efault arg<br> will be ignored (in my opinion), is this expected?<br></blockquote><div><br=
</div><div>Agree, the variable was already defined by the users explicit r=

in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =C2=A0 // returning function pointer/delegate type can have default args?<b= r> =C2=A0 int delegate(int n =3D 10) foo(int x) { ... }<br></blockquote><div><= br></div><div>Sure, why not? If the recipient is auto, then it should inher= it those properties.</div><div><br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If we can take agreements each other about them, it may be supported.<br></= blockquote><div><br></div><div>+1 for Kenji :)</div></div> --bcaec51a7fe8e6e61b04c83fcaa1--
Aug 27 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 26 Aug 2012 18:26:40 -0400, Manu <turkeyman gmail.com> 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.

OK, I've read all the posts on this, and this is what I think would solve the problem: 1. default parameters are part of the function pointer type, because a function pointer has a type. 2. The mangled name of the function that is assigned to that function pointer does *not* have default parameters mangled in. Only the function pointer type has them. 3. Since the default parameters are part of the type, but not defined by the function it points to, you can use interchangeably functions of the same type which define default parameters or not (or define different ones). The default parameters follow the function pointer variable. 4. If a template instantiates with a function type that takes a default parameter, that default parameter is mangled as part of the template type. There is no way around this. But the mangling of the default parameter is *separate* from the mangling of the function type. We can probably implement this as a library feature, but I lack the full template-fu skills to do it. It would be nice to have the compiler do this for us, but I don't know the work involved. Here is a pseudocode type we may be able to use: struct DefaultParamFuncPtr(F, alias T...) if(is(F == function) && isValues!T) // no idea how to define isValues { F funcptr; static T defaultparams; alias funcptr this; // allow this type to act as a straight F, or accept an F to rebind to a different function typeof(funcptr()) opCall(X...)(X params) if(X is a prefix of F's args) // no idea how to write this constraint :) { // construct the rest of the tuple for params given defaultparams typeof(F's args) realtuple = params ~ defaultparams[params.length..$]; // construct the full call parameters return funcptr(realtuple); } } Yeah, it would be really nice to do this in the compiler, but I think the above describes what I would consider to be an equivalent type. The default parameters live as metadata in the type of the function pointer, but are separate from the function type that it points to. -Steve
Aug 27 2012
parent Don Clugston <dac nospam.com> writes:
On 27/08/12 16:16, Steven Schveighoffer wrote:
 On Sun, 26 Aug 2012 18:26:40 -0400, Manu <turkeyman gmail.com> 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.

OK, I've read all the posts on this, and this is what I think would solve the problem: 1. default parameters are part of the function pointer type, because a function pointer has a type. 2. The mangled name of the function that is assigned to that function pointer does *not* have default parameters mangled in. Only the function pointer type has them. 3. Since the default parameters are part of the type, but not defined by the function it points to, you can use interchangeably functions of the same type which define default parameters or not (or define different ones). The default parameters follow the function pointer variable.

This sounds like sloppy thinking. I _think_ what you are saying is that there should be implicit conversions from one function pointer type, to any other that has the same basic declaration, but different default arguments. But then you get problems with IFTI. void foo( void function(int x), double) {} void foo( void function(int x), int) {} void function(int x = 10) bar; foo(bar, 5); // fails -- ambiguous. Both overloads match with implicit conversions. But really, it seems to me that this whole feature is just syntax sugar for one special case of currying.
Aug 28 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec54fb62433335704c8403807
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 17:03, foobar <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 ;) --bcaec54fb62433335704c8403807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 17:03, foobar <span dir=3D"ltr= ">&lt;<a href=3D"mailto:foo bar.com" target=3D"_blank">foo bar.com</a>&gt;<= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">This discussion is all sorts of wrong. Whoever said that = defargs are metadata (Manu?) was right. Therefore it would make sense to im= plement a general metadata facility for D and use *that* for defargs. C++11= has annotations, so that&#39;s the place to start looking at. D has alread= y enough of those pesky special case features, let&#39;s not add yet anothe= r one at the expense of a more general metadata/annotation mechanism which = eventually would be added anyway due to popular demand.</div> </blockquote></div><br><div>Yes, I suggested this as a possibility above, b= ut nobody commented. It seems like it might solve 2 problems with one stone= ;)</div> --bcaec54fb62433335704c8403807--
Aug 27 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Aug 2012 09:23:54 -0400, kenji hara <k.hara.pg gmail.com> wrote:

 I think that the function type and its mangled name must not contain
 the default args, then I can agree with Walter at the point.

 But, I think the variables of function pointers and delegates still
 can have default args as a part of their declarations.
 (It will be a part of VarDeclaration, not a part of TypeFunction)
 In following case, the default arg looks like a part of the type, but
 actually is a part of the declaration of fp.

I think the type of the function pointer and the type (and mangling) of the function are two separate types. One is a function pointer, one is a function. You only need to mangle the function, not the pointer type. Consider this rough equivalent (not sure how to write the constraints): struct callWithN(F, int n) if(F is a function which takes an int as its last arg) { F funcptr; auto opCall(T...)(T t) if(T is equivalent to F's args) { return funcptr(t); } auto opCall(T...)(T t) if(T is equivalent to F's args, except for last int arg) { return funcptr(t, n); } } I think the above (with correct template constraints) is equivalent to defining a function pointer with a default integer argument. Note that the function it points to has *nothing* to do with default args, and so should be mangled like any other function. So I think the default args have to be part of the pointer type, just not the function type.
 void function(int n = 10) fp;
 pragma(msg, typeof(fp));  // should print void function(int), because
 default args are not a part of type.

No. They are part of the function pointer type.
   // fp will *inherit* default args from its initializer, or not?
   auto fp = (int n = 10){}

Yes, this should be equivalent to: void function(int = 10) fp = (int n){};
   // what is the actual default arg of fp?
   void function(int n = 10) fp1 = (int n = 20){}

compiler error. Even if it should be able to reassign a default arg 10 to a default arg 20 function pointer, allowing the above to compile would be extremely confusing, and there is no real reason to allow it. Use the property of the function pointer that gets the function pointer type without the default params (see below).
   void function(int n) fp2 = (int n = 30){}

30
   void function(int n = 40) fp3 = (int n){}

40
   // fp has ambiguous default arg, or has no default arg?
   auto fp1 = some_runtime_condition ? (int n = 10){} : (int n = 20){} ;

Compiler error. You can't define the type differently based on a runtime condition.
   // more complicated case, first defarg is same, then it will be  
 *inherited*?
   auto fp2 = some_runtime_condition ? (int n = 10, string s =
 "hello"){} : (int n = 10, string s = "world"){} ;

Again, two different types. Error.
   int function(int n = 10) fp;   // default arg of the first parameter  
 is 10
   fp = (int n = 20){ return n; }  // function literal's default arg
 will be ignored (in my opinion), is this expected?

I think actually, this should be a compiler error, but it would be a valid choice to make this simply ignore the secondary default arg. Here is what I would like to happen: Given two sets of default parameter tuples X and Y, where X is not a prefix of Y, and Y is not a prefix of X, a function pointer with default args X cannot be assigned from a function pointer with default args Y. Given X and Y where X is a prefix of Y, a function pointer with default args Y can be assigned from a function pointer with default args X. However, the opposite will not be true. However, we should define a function pointer property (e.g. funcptr) which gives naked access to the underlying function pointer. So if you had fx with default args X, and fy with default args Y, and both pointed at functions with the same parameter types, then you could do: fx.funcptr = fy.funcptr; fy.funcptr = fx.funcptr; If this is too complicated, then just allowing all functions with the same underlying function parameter types to be freely assignable also is a valid (but IMO more confusing) choice. Given the above, I think it would be prudent to have the default args returnable via a property or a __traits command. e.g.: auto tupleOfDefaultArgs = fx.defargs;
   // returning function pointer/delegate type can have default args?
   int delegate(int n = 10) foo(int x) { ... }

Of course. Default args are part of the pointer type. -Steve
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51a7fe87acfff04c8413cdb
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 17:51, Andrei Alexandrescu
<SeeWebsiteForEmail 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 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. --bcaec51a7fe87acfff04c8413cdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 17:51, Andrei Alexandrescu <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org" target= =3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"> <div class=3D"im">On 8/27/12 7:03 AM, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> =C2=A0 =C2=A0 If we can take agreements each other about them, it may be su= pported.<br> <br></div> +1 for Kenji :)<br> </blockquote> <br> I think the matter here is that we&#39;re looking at adding very significan= t complexity to the language for a feature with at best minor, marginal ben= efits.<br></blockquote><div><br></div><div>... what?</div><div>We&#39;re no= t talking about <i>adding</i> anything, we&#39;re talking about a bug.</div=

ed, it should work fine under the existing design (hence the bug report), b= ut it seems some design changes may a) make more sense, and also b) simplif= y implementation/fixing the bug.</div> <div>That seems fine, but rather than fixing said implementation bug, the f= eature was just removed from the language, which was coincidentally a major= breaking change.</div><div><br></div><div><div>Does the dmd implementation= define the D language?</div> </div><div><br></div><div><div>I&#39;m sure there&#39;s lots of bugs in var= ious features that could be solved by removing the feature completely.</div=
<div>I encounter problems using &#39;ref&#39; and &#39;in&#39; all the tim=

<br class=3D"Apple-interchange-newline"></div><div>The feature was obviousl= y intended, someone took the time to put it there in the first place, and p= eople use it.</div><div>It&#39;s implementation is apparently not perfect, = and needs to be clarified, maybe that requires a design tweak. That seems m= ore what Kenji is talking about to me.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Default argume= nts add no power to the language, you can quote me on that.<br></blockquote=

n in D is broken? Why have I used a feature so much if it offers nothing?</= div><div>The fact the bug even exists implies that someone saw value in the= feature in the first place...</div> <div><br></div><div>I&#39;m not sure how you define &#39;power&#39;, but de= fault args certainly offer convenience. It also allows the default to be ch= anged universally in one place.</div><div>I wouldn&#39;t want to find the l= ocation 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 explicit= ly intend that value in this particular case.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A wrong was fi= xed with a simplifying solution. That broke some code. Granted, the code co= uld be made to work with a much more complicated (and complicating) solutio= n. Is it worth it? At this point in D&#39;s development, do we want to go f= ull-bore about something that complicates the language to very little benef= it, particularly considering we already have so many balls in the air? I th= ink it&#39;s reasonable to look into fixing the code and calling it a day.<= br> </blockquote><div><br></div><div>A &#39;wrong&#39;? What a subjective opini= on. Default args are useful, and I absolutely appreciated the uniformity D = seemed to offer in this respect (ie, all kinds of function definition suppo= rted them).</div> <div>How do you define &#39;fixing the code&#39;? The &#39;fix&#39; is a ma= jor breaking change.=C2=A0Usually people are extremely phobic of the possib= ility of breaking changes in even minor cases,=C2=A0yet this is relatively = severe.</div> <div><br></div><div>Far more important changes have been rejected on the gr= ounds that they&#39;re breaking changes alone...</div><div><br></div><div>I= f a solid solution is too difficult to implement, or isn&#39;t worth the ti= me right now, then just put the bug back. It was such a minor bug in a very= contrived case, and better than the fix.</div> <div><br></div><div><br><div class=3D"gmail_quote">On 27 August 2012 17:53,= Andrei Alexandrescu=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsit= eForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&g= t;</span>=C2=A0wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex">On 8/27/12 7:34 AM, Manu wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l= eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">Yes, I suggested this as a possibility above, but nobody = commented. It</div><div class=3D"im">seems like it might solve 2 problems w= ith one stone ;)<br></div></blockquote><br>Whilst I agree a metadata facili= ty is an interesting topic to look into, I think default arguments for func= tions is a poor motivating example.</blockquote> <div><br></div><div>I agree. It was just an interesting parallel that I not= iced.</div></div></div></div> --bcaec51a7fe87acfff04c8413cdb--
Aug 27 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
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.
Aug 27 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Aug 27 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Aug 27 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
I think that D should be consistent with rules of types 
derivation, in particular the pointer one. Two pointer types 
should be same if and only if types they pointer are the same. 
Breaking this rule would result in language complexity.

In case when default arguments are part of the type, default 
arguments must be written in declaration of a function pointer, 
moreover function pointers with different default arguments would 
be different types. So, besides of getting convenient usage of a 
shorter function call a user would have carry a particular 
default value with every declaration/definition he writes. Also 
similar functions pointers with different default arguments would 
not be interchangeable because they are different types. I think 
that such constraints would make the proposal a net loss to D 
contribution.

Also, making default arguments a part of a definition would break 
C/C++ legacy rules which claim that a function is characterized 
by its return value and number, order and types of its 
parameters. Although, it not necessarily mean that this rule 
cannot be broken, but it at least requires strong reasons, 
however as it is discussed, the proposal would result in a 
unclear usage, increased language complexity, subtle bugs and 
implementation issues.
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--14dae9cdc68b62826b04c845b306
Content-Type: text/plain; charset=UTF-8

On 27 August 2012 23:54, Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/27/2012 7:03 AM, foobar 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.

The annotations design discussed was about annotating declarations, not types.

And that may be fine for default args too. I've personally only ever used them where I've explicitly defined them. --14dae9cdc68b62826b04c845b306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 27 August 2012 23:54, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">On 8/27/2012 7:03 AM, foobar wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> This discussion is all sorts of wrong. Whoever said that defargs are metada= ta<br> (Manu?) was right. Therefore it would make sense to implement a general met= adata<br> facility for D and use *that* for defargs. C++11 has annotations, so that&#= 39;s the<br> place to start looking at. D has already enough of those pesky special case= <br> features, let&#39;s not add yet another one at the expense of a more genera= l<br> metadata/annotation mechanism which eventually would be added anyway due to= <br> popular demand.<br> </blockquote> <br></div> The annotations design discussed was about annotating declarations, not typ= es.<br> </blockquote></div><br><div>And that may be fine for default args too. I&#3= 9;ve personally only ever used them where I&#39;ve explicitly defined them.= </div> --14dae9cdc68b62826b04c845b306--
Aug 27 2012
prev sibling next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 27 August 2012 at 20:29:15 UTC, deadalnix wrote:
 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.

I may be considered rude, but as I have understood from the first post Manu 1) decided to use a not fully designed language feature 2) used this feature in public API when working with DLLs (which is by itself a problematic area) 3) integrated this with other language in a a way that require substantial rewrite and possibly redesign 4) updated compiler which I consider a process of looking for problems and no excuse for making code-break change. Anyway, older version of compiler is available.
Aug 27 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/27/12 2:28 PM, Jonathan M Davis wrote:
 On Monday, August 27, 2012 23:22:39 foobar wrote:
 All true, except one crucial fact: DMD gets critical bug fixes
 incorporated with new features in the same release. This leaves a
 poor choice to the programmer, either he sticks with older
 compiler version and can't get any critical bug fixes, or he
 updates the compiler to latest version with all the bug fixes but
 risks breakage of code due to new features (which is _exactly_
 what happened to manu).

Except that the change which is causing Manu problems _isn't_ a new feature. It's a bug fix. So, better versioning wouldn't necessarily have helped him any at all.

Yah, this particular example is more of an example of the limitation of the stable/dev approach. Nevertheless, I do think we should switch to it. But more importantly we must first move to an integrally automated, scripted method of releasing software. The amount of manual drudgery that goes into today's release process makes my blood curd. To paraphrase a famous quote, we can't improve what we don't have. Andrei
Aug 27 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-27 23:28, Jonathan M Davis wrote:

 Except that the change which is causing Manu problems _isn't_ a new feature.
 It's a bug fix. So, better versioning wouldn't necessarily have helped him any
 at all. At best, if we had a more complex versioning scheme, it could be
 decided that the bug fix was potentially disruptive enough that it should only
 be fixed in a more major release, but _every_ bug fix risks breaking code,
 especially when code could be relying on the buggy behavior.

The fix for this particular bug was to remove a language feature. I don't think it would be wise to put that change in a minor release. It doesn't matter why the feature was removed. If a feature is remove from the language it should only be put in a major release, period. -- /Jacob Carlborg
Aug 28 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 27 August 2012 at 21:08:48 UTC, Maxim Fomin wrote:
 On Monday, 27 August 2012 at 20:29:15 UTC, deadalnix wrote:
 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.

I may be considered rude, but as I have understood from the first post Manu 1) decided to use a not fully designed language feature 2) used this feature in public API when working with DLLs (which is by itself a problematic area) 3) integrated this with other language in a a way that require substantial rewrite and possibly redesign 4) updated compiler which I consider a process of looking for problems and no excuse for making code-break change. Anyway, older version of compiler is available.

All true, except one crucial fact: DMD gets critical bug fixes incorporated with new features in the same release. This leaves a poor choice to the programmer, either he sticks with older compiler version and can't get any critical bug fixes, or he updates the compiler to latest version with all the bug fixes but risks breakage of code due to new features (which is _exactly_ what happened to manu). It's high time for D to split its dev version from the stable one. All major software have this, Debian, Linux, browsers (chrome, Firefox, etc), Windows, etc, etc. This is an ancient concept practiced for decades now in the software world.
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51a7fe8470fd804c845ee07
Content-Type: text/plain; charset=UTF-8

On 28 August 2012 00:03, Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/27/2012 3:32 AM, Manu wrote:

 Here's an advanced trick I use a lot since D doesn't extern to static C++
 methods (heavily simplified, this is way out of context):

 struct CPPClass
 {
      this()
      {
          // not my actual code, but effectively, write 'this' and the C++
 method
 pointer into a delegate on initialisation [I wrap this process up using
 magic]
          void** pDelegate = cast(void**)&**cppNonVirtualMethod;
          pDelegate[0] = this;
          pDelegate[1] = pCPPMethodPointer;
      }

      void delegate(int x = 0) cppNonVirtualMethod; // C++ methods often
 have
 default args

void delegate(int x) cppNonVirtualMethod; void callCppNonVirtualMethod(int x) { (*cppNonVirtualMethod)(x); } void callCppNonVirtualMethod() { callCppNonVirtualMethod(0); } With inlining on, the calls to the second overload should disappear, and you have the same code generated as you would for the default arg method. You could probably reduce the typing with some sort of mixin template, but this is the basic idea.

I've actually considered this approach, and the overload isn't required in this case, since the true method can have a default arg. The same pattern can apply at the global scope. There are 2 reasons I didn't go for it: Every api call is a double-call with inlining turned off (debug builds). Debug builds are already slow enough, I didn't want to base a design decision on that when it was perfectly syntactically reasonable to call through the function pointers directly. __forceinline would address this concern. (I really need this anyway for the simd api. simd intrinsics are all wrapped in templates; if these are not inlined, making a function call for every math opcode, it's gonna be waaaaay slower than using the fpu) And the second is forward declarations and function definitiona appearing within the same file (I have a feature request on this). The API is easily defined by the function pointer, but since the definition needs to define the default args, what now needs to be defined is a forward declaration/prototype. The trouble is, my module magic mixin can't produce the bodies for the stubs it finds because a prototype and definition can't appear in the same file. void functionDecl(int x = 10); // declaration by user (ideally with an custom attribute: engine_import, which would inform the magic generating mixin to produce a stub and linkage code for this) // **** magically generated by a mixin: **** void function(int) __functionDecl_ptr; __forceinline void functionDecl(int x) { __functionDecl_ptr(x); } // ************** static this() { __functionDecl_ptr = importExtern("functionDecl"); } // ************** Sadly, there's a lot missing from the language to be able to do that, but I hope we can reach that place one day. --bcaec51a7fe8470fd804c845ee07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 August 2012 00:03, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div class=3D"im">On 8/27/2012 3:32 AM, Manu wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Here&#39;s an advanced trick I use a lot since D doesn&#39;t extern to stat= ic C++<br> methods (heavily simplified, this is way out of context):<br> <br> struct CPPClass<br> {<br> =C2=A0 =C2=A0 =C2=A0this()<br> =C2=A0 =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// not my actual code, but effectively, w= rite &#39;this&#39; and the C++ method<br> pointer into a delegate on initialisation [I wrap this process up using mag= ic]<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void** pDelegate =3D cast(void**)&amp;<u>= </u>cppNonVirtualMethod;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pDelegate[0] =3D this;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pDelegate[1] =3D pCPPMethodPointer;<br> =C2=A0 =C2=A0 =C2=A0}<br> <br> =C2=A0 =C2=A0 =C2=A0void delegate(int x =3D 0) cppNonVirtualMethod; // C++ = methods often have<br> default args<br> </blockquote> <br></div> =C2=A0 =C2=A0 =C2=A0 =C2=A0void delegate(int x) cppNonVirtualMethod;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0void callCppNonVirtualMethod(int x) { (*cppNonVi= rtualMethod)(x); }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0void callCppNonVirtualMethod() { callCppNonVirtu= alMethod(0); }<br> <br> With inlining on, the calls to the second overload should disappear, and yo= u have the same code generated as you would for the default arg method. You= could probably reduce the typing with some sort of mixin template, but thi= s is the basic idea.</blockquote> <div><br></div><div>I&#39;ve actually considered this approach, and the ove= rload isn&#39;t required in this case, since the true method can have a def= ault arg. The same pattern can apply at the global scope.</div><div>There a= re 2 reasons I didn&#39;t go for it:</div> <div><br></div><div>Every api call is a double-call with inlining turned of= f (debug builds). Debug builds are already slow enough, I didn&#39;t want t= o base a design decision on that when it was perfectly syntactically reason= able to call through the function pointers directly.</div> <div>__forceinline would address this concern. (I really need this anyway f= or the simd api. simd intrinsics are all wrapped in templates; if these are= not inlined, making a function call for every math opcode, it&#39;s gonna = be waaaaay slower than using the fpu)</div> <div><br></div><div>And the second is=C2=A0forward declarations and=C2=A0fu= nction definitiona appearing within the same file (I have a feature request= on this).</div><div>The API is easily defined by the function pointer, but= since the definition needs to define the default args, what now needs to b= e defined is a forward declaration/prototype.</div> <div>The trouble is, my module magic mixin can&#39;t produce the bodies for= the stubs it finds because a prototype and definition can&#39;t appear in = the same file.</div><div><br></div><div>void functionDecl(int x =3D 10); //= declaration by user (ideally with an custom attribute: engine_import, whi= ch would inform the magic generating mixin to produce a stub and linkage co= de for this)</div> <div><br></div><div>// **** magically generated by a mixin: ****</div><div>= void function(int) __functionDecl_ptr;</div><div>__forceinline void functio= nDecl(int x)<br></div><div>{</div><div>=C2=A0=C2=A0 __functionDecl_ptr(x);<br>}</div><div><div>// **************</div></div><di= v>static this()</div><div>{</div><div>=C2=A0=C2=A0__functionDecl_ptr =3D im= portExtern(&quot;functionDecl&quot;);</div><div>}</div><div>// ************= **</div> <div><br></div><div>Sadly, there&#39;s a lot missing from the language to b= e able to do that, but I hope we can reach that place one day.</div></div> --bcaec51a7fe8470fd804c845ee07--
Aug 27 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 27, 2012 23:22:39 foobar wrote:
 All true, except one crucial fact: DMD gets critical bug fixes
 incorporated with new features in the same release. This leaves a
 poor choice to the programmer, either he sticks with older
 compiler version and can't get any critical bug fixes, or he
 updates the compiler to latest version with all the bug fixes but
 risks breakage of code due to new features (which is _exactly_
 what happened to manu).

Except that the change which is causing Manu problems _isn't_ a new feature. It's a bug fix. So, better versioning wouldn't necessarily have helped him any at all. At best, if we had a more complex versioning scheme, it could be decided that the bug fix was potentially disruptive enough that it should only be fixed in a more major release, but _every_ bug fix risks breaking code, especially when code could be relying on the buggy behavior. - Jonathan M Davis
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec54ee84ae00dcf04c846044f
Content-Type: text/plain; charset=UTF-8

On 28 August 2012 00:08, Maxim Fomin <maxim maxim-fomin.ru> wrote:

 On Monday, 27 August 2012 at 20:29:15 UTC, deadalnix wrote:

 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.

I may be considered rude, but as I have understood from the first post Manu 1) decided to use a not fully designed language feature

Where is that stated? It appeared to be a perfectly good, working, and awesome(!) language feature. 2) used this feature in public API when working with DLLs (which is by
 itself a problematic area)

Are you suggesting using DLL's is asking for trouble? Dynamic linkage is a fundamental part of software. 3) integrated this with other language in a a way that require substantial
 rewrite and possibly redesign

D will interact with other languages in the real world, if anything, my doing so and talking about my approach and experience is a service. 4) updated compiler

No shit, D has loads of bugs which are rapidly fixed all the time. which I consider a process of looking for problems and no excuse for making
 code-break change. Anyway, older version of compiler is available.

Whatever. --bcaec54ee84ae00dcf04c846044f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 August 2012 00:08, Maxim Fomin <span dir= =3D"ltr">&lt;<a href=3D"mailto:maxim maxim-fomin.ru" target=3D"_blank">maxi= m maxim-fomin.ru</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Monday, 27 August 2012 at 20:29:15 UTC, deadalnix wrot= e:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> That guy just have to rework 5 projects. This is quite a lot of work.<br> <br> Obviously, that change have to be done. But you can&#39;t just impose such = a change on users. Their agenda isn&#39;t synchronized with D&#39;s.<br> <br> D NEED a better versioning scheme, as explained MANY times here already.<br=

<br></div> I may be considered rude, but as I have understood from the first post Manu= <br> 1) decided to use a not fully designed language feature<br></blockquote><di= v><br></div><div>Where is that stated? It appeared to be a perfectly good, = working, and awesome(!) language feature.</div><div><br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> 2) used this feature in public API when working with DLLs (which is by itse= lf a problematic area)<br></blockquote><div><br></div><div>Are you suggesti= ng using DLL&#39;s is asking for trouble? Dynamic linkage is a fundamental = part of software.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> 3) integrated this with other language in a a way that require substantial = rewrite and possibly redesign<br></blockquote><div><br></div><div>D will in= teract with other languages in the real world, if anything, my doing so and= talking about my approach and experience is a service.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> 4) updated compiler<br></blockquote><div><br></div><div>No shit, D has load= s of bugs which are rapidly fixed all the time.</div><div><br></div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> which I consider a process of looking for problems and no excuse for making= code-break change. Anyway, older version of compiler is available.<br> </blockquote></div><br><div>Whatever.</div> --bcaec54ee84ae00dcf04c846044f--
Aug 27 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--e89a8ff1c47c15ad9a04c84622a4
Content-Type: text/plain; charset=UTF-8

On 28 August 2012 00:11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/27/2012 3:32 AM, Manu wrote:

 Almost all my API's are dynamically bound to foreign code, eg:

 extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1, ref
 const(Vector2) v2, ref const(Color) color = Color.white, BlendMode
 blendMode =
 BlendMode.Disabled ) fillTriangle2D;

These can all be handled in a straightforward (but admittedly wordy) method of wrapping the call to the function pointer in an overloaded function.

They can, see my prev post. It's less readable, less maintainable, more obscure to those reading the code... the language had an awesome feature that addressed it directly. When mixins get involved, readability, syntax highlighting, and other basic IDE services all go out the window. Perhaps the most important one that I forgot; debugging becomes VERY annoying. Try stepping into an engine API when it's wrapped up with magic... F10 (jumps to a rubbish API file, cursor disappears, stub code doesn't actually exist). Continue pressing F10 for a while until it eventually finds it's way into the function pointer. Repeat when leaving the function >_< .. Again, __forceinline would address this. I understand that you've probably got so many of these, it's drudgery to
 make the edits.

It would be annoying. Question: are the default values all of the form T.init? I.e. is
 Color.white == Color.init?

No, I don't think so. Color inits to black. Many enums also have an Unknown state. and float init's to NaN for some crazy reason ;) --e89a8ff1c47c15ad9a04c84622a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On 28 August 2012 00:11, Walter Bright <= span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target= =3D"_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> <div class=3D"im">On 8/27/2012 3:32 AM, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> Almost all my API&#39;s are dynamically bound to foreign code, eg:<br> <br></div><div class=3D"im"> extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1, ref<= br> const(Vector2) v2, ref const(Color) color =3D Color.white, BlendMode blendM= ode =3D<br> BlendMode.Disabled ) fillTriangle2D;<br> </div></blockquote> <br> These can all be handled in a straightforward (but admittedly wordy) method= of wrapping the call to the function pointer in an overloaded function.<br=
</blockquote><div><br></div><div>They can, see my prev post.</div><div>

to those reading the code... the language had an awesome feature that addr= essed it directly.</div><div>When mixins get involved, readability, syntax = highlighting, and other basic IDE services all go out the window.</div> <div><br></div><div>Perhaps the most important one that I forgot; debugging= becomes VERY annoying. Try stepping into an engine API when it&#39;s wrapp= ed up with magic... F10 (jumps to a rubbish API file, cursor disappears, st= ub code doesn&#39;t actually exist). Continue pressing F10 for a while unti= l it eventually finds it&#39;s way into the function pointer. Repeat when l= eaving the function &gt;_&lt; ..=C2=A0Again, __forceinline would address th= is.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> I understand that you&#39;ve probably got so many of these, it&#39;s drudge= ry to make the edits.<br></blockquote><div><br></div><div>It would be annoy= ing.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Question: are the default values all of the form T.init? I.e. is Color.whit= e =3D=3D Color.init?<br></blockquote><div><br></div><div>No, I don&#39;t th= ink so. Color inits to black. Many enums also have an Unknown state. and fl= oat init&#39;s to NaN for some crazy reason ;)</div> </div> --e89a8ff1c47c15ad9a04c84622a4--
Aug 27 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 27, 2012 14:54:52 Andrei Alexandrescu wrote:
 On 8/27/12 2:28 PM, Jonathan M Davis wrote:
 Except that the change which is causing Manu problems _isn't_ a new
 feature. It's a bug fix. So, better versioning wouldn't necessarily have
 helped him any at all.

Yah, this particular example is more of an example of the limitation of the stable/dev approach. Nevertheless, I do think we should switch to it.

Oh, I agree. I'm just saying that this is not a problem that a major.minor versioning system would solve. Such a versioning scheme could definitely be beneficial, but I think that many of those asking for it seriously overestimate how much it will reduce breaking changes. Aside from whatever deprecations occur (the number of which has been diminishing), they're almost exclusively caused by bug fixes.
 But more importantly we must first move to an integrally automated,
 scripted method of releasing software. The amount of manual drudgery
 that goes into today's release process makes my blood curd. To
 paraphrase a famous quote, we can't improve what we don't have.

Agreed. - Jonathan M Davis
Aug 27 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 27 August 2012 at 21:29:06 UTC, Jonathan M Davis wrote:
 On Monday, August 27, 2012 23:22:39 foobar wrote:
 All true, except one crucial fact: DMD gets critical bug fixes
 incorporated with new features in the same release. This 
 leaves a
 poor choice to the programmer, either he sticks with older
 compiler version and can't get any critical bug fixes, or he
 updates the compiler to latest version with all the bug fixes 
 but
 risks breakage of code due to new features (which is _exactly_
 what happened to manu).

Except that the change which is causing Manu problems _isn't_ a new feature. It's a bug fix. So, better versioning wouldn't necessarily have helped him any at all. At best, if we had a more complex versioning scheme, it could be decided that the bug fix was potentially disruptive enough that it should only be fixed in a more major release, but _every_ bug fix risks breaking code, especially when code could be relying on the buggy behavior. - Jonathan M Davis

I guess your definition of stable is different than mine. "Accepts invalid" bugs should never be fixed on the current stable branch as they introduce a breaking change unless it's a matter of a security problem. All compilers have a list of accepts invalid bugs and no one "fixes" them on the stable/release branch exactly because it will break existing code as evidently shown by manu's posts. Python introduced version 3 to handle this and Ruby had version 1.9, all the while both the stable and the next-version branches got bug-fixes. D was moved to Git long ago which trivially allows such branching schemes so there really no excuse to stick with the current flawed system except inertia.
Aug 28 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235452ed2c61cc9304c8550626
Content-Type: text/plain; charset=UTF-8

On 28 August 2012 16:50, Daniel Murphy <yebblies nospamgmail.com> wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1446.1346070222.31962.digitalmars-d puremagic.com...
 Default arguments just do not make sense with function pointers, because
 they
 don't follow the function pointer, because it's a _pointer_ and has no
 knowledge of what it's pointing to. It's only at the declaration point of
 the
 function that the default argument exists, and that has _nothing_ to do
 with
 the function pointer. You might as well ask a reference of type Object
 what
 the arguments used to construct the derived class that it actually refers
 to
 were as expect a function pointer to have any clue about default

 to
 the function that it points to.

 - Jonathan M Davis

Yes, this. I looked into fixing issue 3866 earlier this year, and Kenji's list sounds very familiar. It comes down to - function pointers are not function declarations and therefore can't do everything function declarations do, such as overloading and default arguments. This is the price of being able to reassign them. Yes it is possible to make them work the way Manu has been using them, but the solution is messy and I seriously doubt it's worth it. I agree with everything Andrei has said about this. I don't consider putting default arguments back in the type a valid approach because of the reason above, so that leaves giving function pointer variables the ability to have default arguments. This seems to me like a really dumb corner case with the same problems.

Well that's painful for a number of reasons. Other than the fact that I need to rewrite a bunch of code, I can't actually produce a solution that works as well in lieu of some feature requests. A language feature should be deprecated for some time before it is surprise-removed like that... that would allow some time to discuss and possibly implement support for work-arounds. Since I'll need to create wrapper functions and stubs for *everything*, I really need __forceinline, or debug builds will really suffer. (That said, I need it anyway for heaps of other stuff (SIMD in particular), but this really seals the deal.) Without it, all function calls require call-through stubs, all my API calls become double-calls, and debugging becomes really tedious (stepping into and out of stubs generated by magic that don't really exist every time you press F11 >_<). Also, in my case, I really need to be able to forward declare a function in the same file as it is defined. The user needs to write the prototypes, and then magic can scan for the prototypes and generate the stub its self, but they can't currently appear in the same file like in C/C++. Without both of those things, my new solutions will be worse. More verbose, difficult to read&maintain, slower, and really annoying to debug. Why are you so against default arguments associating with a declaration? Why is the solution messy? Default arguments simplify code. If a default is used frequently, it's better to define it in one place, that is easy to change, and appears with the definition. It's self-documenting, and very convenient. --00235452ed2c61cc9304c8550626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 August 2012 16:50, Daniel Murphy <span dir= =3D"ltr">&lt;<a href=3D"mailto:yebblies nospamgmail.com" target=3D"_blank">= yebblies nospamgmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"> &quot;Jonathan M Davis&quot; &lt;<a href=3D"mailto:jmdavisProg gmx.com">jmd= avisProg gmx.com</a>&gt; wrote in message<br> news:mailman.1446.1346070222.31962.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt;<br> &gt; Default arguments just do not make sense with function pointers, becau= se<br> &gt; they<br> &gt; don&#39;t follow the function pointer, because it&#39;s a _pointer_ an= d has no<br> &gt; knowledge of what it&#39;s pointing to. It&#39;s only at the declarati= on point of<br> &gt; the<br> &gt; function that the default argument exists, and that has _nothing_ to d= o<br> &gt; with<br> </div>&gt; the function pointer. You might as well ask a reference of type = Object<br> <div class=3D"im">&gt; what<br> &gt; the arguments used to construct the derived class that it actually ref= ers<br> &gt; to<br> &gt; were as expect a function pointer to have any clue about default argum= ents<br> &gt; to<br> &gt; the function that it points to.<br> &gt;<br> </div>&gt; - Jonathan M Davis<br> <br> Yes, this. =C2=A0I looked into fixing issue 3866 earlier this year, and Ken= ji&#39;s<br> list sounds very familiar.<br> <br> It comes down to - function pointers are not function declarations and<br> therefore can&#39;t do everything function declarations do, such as overloa= ding<br> and default arguments. =C2=A0This is the price of being able to reassign th= em.<br> <br> Yes it is possible to make them work the way Manu has been using them, but<= br> the solution is messy and I seriously doubt it&#39;s worth it. =C2=A0I agre= e with<br> everything Andrei has said about this.<br> <br> I don&#39;t consider putting default arguments back in the type a valid app= roach<br> because of the reason above, so that leaves giving function pointer<br> variables the ability to have default arguments. =C2=A0This seems to me lik= e a<br> really dumb corner case with the same problems.<br> </blockquote></div><br><div>Well that&#39;s painful for a number of reasons= .</div><div>Other than the fact that I need to rewrite a bunch of code, I c= an&#39;t actually produce a solution that works as well in lieu of some fea= ture requests.</div> <div><br></div><div>A language feature should be deprecated for some time b= efore it is surprise-removed like that... that would allow some time to dis= cuss and possibly implement support for work-arounds.</div><div><br></div> <div>Since I&#39;ll need to create wrapper functions and stubs for <u>every= thing</u>, I really need __forceinline, or debug builds will really suffer.= (That said, I need it anyway for heaps of other stuff (SIMD in particular)= , but this really seals the deal.)</div> <div>Without it, all function calls require call-through stubs, all my API = calls become double-calls, and debugging becomes really tedious (stepping i= nto and out of stubs generated by magic that don&#39;t really exist every t= ime you press F11 &gt;_&lt;).</div> <div><br></div><div>Also, in my case, I really need to be able to forward d= eclare a function in the same file as it is defined.</div><div>The user nee= ds to write the prototypes, and then magic can scan for the prototypes and = generate the stub its self, but they can&#39;t currently appear in the same= file like in C/C++.</div> <div><br></div><div>Without both of those things, my new solutions will be = worse. More verbose, difficult to read&amp;maintain, slower, and really ann= oying to debug.</div><div><br></div><div><br></div><div>Why are you so agai= nst default arguments associating with a declaration? Why is the solution m= essy?</div> <div>Default arguments simplify code. If a default is used frequently, it&#= 39;s better to define it in one place, that is easy to change, and appears = with the definition. It&#39;s self-documenting, and very convenient.</div> --00235452ed2c61cc9304c8550626--
Aug 28 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 12:14:30 UTC, Manu wrote:
 On 27 August 2012 14:08, Carl Sturtivant <sturtivant gmail.com> 
 wrote:

 extern(C) void function( ref const(Vector2) v0, ref 
 const(Vector2) v1,
 ref const(Vector2) v2, ref const(Color) color = Color.white, 
 BlendMode
 blendMode = BlendMode.Disabled ) fillTriangle2D;

If function pointers could be called with fewer than the prototypical number of arguments, and the remaining arguments be always initialized to their .init defaults, you could perhaps make this sort of thing work without the default argument values by using struct defaults. How would that be deficient?

... no. Color does not .init == Color.white. You're suggesting I define a new type, obscuring the API, every time I want a non-.init default arg? Also, I think it's correct that functions shouldn't be callable without explicit parameters. Default args are carefully selected, and they are always opt-in. 'v2' in this case shouldn't be allowed to default to [ NaN, NaN ] if I omit it.

More specifically, you can get the default initialization of e.g. double to be different as follows. import std.stdio; struct dbl(double init) { double d = init; alias d this; } void main() { dbl!3.142 x; dbl!2.0 y; writeln(x*y); } In the case of an external(C) struct, the D definition can fix up its own default initialization without a new type name even. Color for example could be fixed up to initialize to Color.white by default. And, having the compiler fix up omitted trailing arguments with .init default values could be confined to "opt-in" parameters by a small change to the type system for function pointers as follows. The type of a function pointer could now include the number of trailing parameters that may be defaulted. This does not explode the size of a mangled name much. A syntactic mechanism to indicate which trailing parameters may be defaulted in a function prototype could be added to D. The default would be none with functions declared without that mechanism. This mechanism needs to be a part of the prototype so that it can be used on external(C) functions etcetera. Now only trailing parameters that you intend to be defaulted would would get defaulted with the .init treatment. Others would be compilation errors. Now what's wrong with this if there are no trailing argument defaults except for the .init defaults?
Aug 28 2012
prev sibling next sibling parent "Robert Clipsham" <robert octarineparrot.com> writes:
On Tuesday, 28 August 2012 at 06:53:15 UTC, Jacob Carlborg wrote:
 On 2012-08-27 22:53, Walter Bright wrote:

 The language design requires a 1:1 mapping of mangling to 
 types. Hence
 the compiler design to use the mangling as a hashmap key of 
 types. The
 failure of that approach in this case points to a problem in 
 the
 language design, not a bug in the compiler.

How does this then work when the body of the anonymous functions are different? How will they be identified?

The body of the function has nothing to do with its type.
Aug 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 This change of wind may as well turn a new page in the history 
 of D :o).

<humor>Maybe as soon as the D1 branch stops getting bug fixes, Walter&Co will start a D3 branch where this small breaking change happens.</humor> Bye, bearophile
Aug 28 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args 
 would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.

I think this is the right behavior too. Default arguments are IMHO just a compact way to write some simply related overloaded functions, e.g. thus: int sum(int x, int y = 1 ) { return x + y; } is just a compact way to write int sum(int x, int y) { return x + y; } int sum(int x) { return sum(x, 1); } and a function pointer refers to a single function, so overloading and default arguments are irrelevant to function pointers. It just so happens that the particularly simple overloading abbreviated by a function definition with default arguments is easily optimized by the compiler with only one function arriving at the linker: the most general one. And that's the one whose address is supplied if the unary & operator is applied to it. So that's the problem with 'int sum(int x, int y = 1 ) ...' --- it's not one function under the interpretation above. So how could we interpret int function(int x, int y = 1) sum; in the above interpretation? What's happening right now is that sum is considered to be a single function pointer, so we discard the default to get the most general function type much like the effect of unary & above. So the trouble with the supposed type 'int function(int x, int y = 1)' is that it is not one type, just as the function sum above is not one function. [Speculation mode starts here.] So what if function pointer declarations with defaults are considered to define several function pointers and not just one. e.g. thus: int function(int x, int y = 1) sum; could be taken by the compiler to mean int function(int x, int y) sum; //all the rest call back the general function pointer int function(int x) sum = function sum(int x) { return sum(x,1); } I haven't explored all of the ramifications of this, but it looks as if it solves quite a few problems without changing the type system, or affecting existing code. And there's a simple model of what's going on: overloading, just generalized slightly. This may not be clean enough or general enough. But the basic point that something like 'int function(int x, int y = 1)' is a sequence of types is worth attention. A declaration using a sequence of types should produce a sequence of function pointers under this interpretation. Exactly how "sequence of types" and "sequence of pointers" should be wrapped up for best effect is then the language design decision to make. There are several other interesting ways to go, some involving getting more general and allowing other kinds of overloading with function pointer sequences, not just the special kind that comes from default arguments, but I'll stop here for now.
Aug 28 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Tuesday, 28 August 2012 at 18:52:13 UTC, Andrei Alexandrescu 
wrote:
 On 8/28/12 8:23 AM, Manu wrote:
 Well that's painful for a number of reasons..
 Other than the fact that I need to rewrite a bunch of code,

Walter and Kenji think breaking meaningful existing code is an overriding concern, and I ended up agreeing with them. They will look into a solution that keeps your working code working. This change of wind may as well turn a new page in the history of D :o).

I replied to Walter just now with a way to get a clean mechanism to do this, that's consistent with the existing type system, and with function pointers working exactly as they do now. Carl.
Aug 28 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7bf0f14eb345b304c85abfd8
Content-Type: text/plain; charset=UTF-8

On 28 August 2012 21:52, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org>wrote:

 On 8/28/12 8:23 AM, Manu wrote:

 Well that's painful for a number of reasons..

 Other than the fact that I need to rewrite a bunch of code,

Walter and Kenji think breaking meaningful existing code is an overriding concern, and I ended up agreeing with them. They will look into a solution that keeps your working code working. This change of wind may as well turn a new page in the history of D :o).

Wow, I didn't see that coming. At very least, just put it on a deprecation schedule. I'm happy (perhaps even prefer) to use the alternative approach I've describe if those 2 issues are addressed in some way. --047d7bf0f14eb345b304c85abfd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 August 2012 21:52, Andrei Alexandrescu <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org" target= =3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"> On 8/28/12 8:23 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Well that&#39;s painful for a number of reasons..<div class=3D"im"><br> Other than the fact that I need to rewrite a bunch of code,<br> </div></blockquote> <br> Walter and Kenji think breaking meaningful existing code is an overriding c= oncern, and I ended up agreeing with them.<br> <br> They will look into a solution that keeps your working code working.<br> <br> This change of wind may as well turn a new page in the history of D :o).</b= lockquote><div><br></div><div>Wow, I didn&#39;t see that coming.</div><div>= <br></div><div>At very least, just put it on a deprecation schedule. I&#39;= m happy (perhaps even prefer) to use the alternative approach I&#39;ve desc= ribe if those 2 issues are addressed in some way.</div> </div> --047d7bf0f14eb345b304c85abfd8--
Aug 28 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Tuesday, 28 August 2012 at 21:40:01 UTC, Timon Gehr wrote:
 On 08/28/2012 10:33 PM, Carl Sturtivant wrote:
 On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args 
 would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.

I think this is the right behavior too. Default arguments are IMHO just a compact way to write some simply related overloaded functions, e.g. thus: int sum(int x, int y = 1 ) { return x + y; } is just a compact way to write int sum(int x, int y) { return x + y; } int sum(int x) { return sum(x, 1); } ...

This interpretation is simply wrong. import std.stdio, std.c.stdlib; void* alloca20bytes(void* x = alloca(20)){ return x; } // your suggested transformation: /+void* alloca20bytes(void* x){ return x; } void* alloca20bytes(){ return alloca20bytes(alloca(20)); }+/ // would break the caller: void main(){ auto x = (cast(int*)alloca20bytes())[0..5]; x[] = 0; x[] += 2; writeln(x); }

Function inlining or not in the presence of alloca calls and similar using the existing stack frame are problematic. If the first call was inlined by the compiler, that would un-break the "problem". I suggest that we simply define default arguments via the transformation I suggested, and regard void* alloca20bytes(void* x = alloca(20)){ return x; } as broken. It's not compelling for a lot of reasons. Of course there may be something else wrong with the transformation! Fire away.
Aug 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 29, 2012 01:13:15 Manu wrote:
 On 28 August 2012 21:52, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org>wrote:
 On 8/28/12 8:23 AM, Manu wrote:
 Well that's painful for a number of reasons..
 
 Other than the fact that I need to rewrite a bunch of code,

Walter and Kenji think breaking meaningful existing code is an overriding concern, and I ended up agreeing with them. They will look into a solution that keeps your working code working. This change of wind may as well turn a new page in the history of D :o).

Wow, I didn't see that coming. At very least, just put it on a deprecation schedule. I'm happy (perhaps even prefer) to use the alternative approach I've describe if those 2 issues are addressed in some way.

The funny thing about that is that for the most part, language features which are supposed to be deprecated tend to just stick around instead of getting deprecated, meaning that people keep on using them, and that by the time they're actually deprecated, they'll break that much more code... It's one thing to decide not to make a change becasue we don't want to break code. It's quite another to just keep putting it off to avoid breaking code. That just makes things worse when it finally happens. - Jonathan M Davis
Aug 28 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 27 Aug 2012 19:46:57 +0200
schrieb "foobar" <foo bar.com>:

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

Properties are currently implemented as "strip off the and continue". They are mapped to storage class bit flags, like the others with no special code paths or data structures in place. -- Marco
Aug 28 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Tuesday, 28 August 2012 at 23:34:54 UTC, Carl Sturtivant wrote:
 On Tuesday, 28 August 2012 at 21:40:01 UTC, Timon Gehr wrote:
 On 08/28/2012 10:33 PM, Carl Sturtivant wrote:
 On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright 
 wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default 
 args would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.

I think this is the right behavior too. Default arguments are IMHO just a compact way to write some simply related overloaded functions, e.g. thus: int sum(int x, int y = 1 ) { return x + y; } is just a compact way to write int sum(int x, int y) { return x + y; } int sum(int x) { return sum(x, 1); } ...

This interpretation is simply wrong. import std.stdio, std.c.stdlib; void* alloca20bytes(void* x = alloca(20)){ return x; } // your suggested transformation: /+void* alloca20bytes(void* x){ return x; } void* alloca20bytes(){ return alloca20bytes(alloca(20)); }+/ // would break the caller: void main(){ auto x = (cast(int*)alloca20bytes())[0..5]; x[] = 0; x[] += 2; writeln(x); }

Function inlining or not in the presence of alloca calls and similar using the existing stack frame are problematic. If the first call was inlined by the compiler, that would un-break the "problem". I suggest that we simply define default arguments via the transformation I suggested, and regard void* alloca20bytes(void* x = alloca(20)){ return x; } as broken. It's not compelling for a lot of reasons. Of course there may be something else wrong with the transformation! Fire away.

Another, more conservative, approach would be for the compiler to regard the non-general functions in such a group created by my transformation to be always inlined, so the default parameters are always evaluated before the call. Then your interesting example would work the way you expect.
Aug 29 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec54ee84a650f8f04c8645acc
Content-Type: text/plain; charset=UTF-8

On 29 August 2012 04:31, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Wednesday, August 29, 2012 01:13:15 Manu wrote:
 On 28 August 2012 21:52, Andrei Alexandrescu

 <SeeWebsiteForEmail erdani.org>wrote:
 On 8/28/12 8:23 AM, Manu wrote:
 Well that's painful for a number of reasons..

 Other than the fact that I need to rewrite a bunch of code,

Walter and Kenji think breaking meaningful existing code is an


 concern, and I ended up agreeing with them.

 They will look into a solution that keeps your working code working.

 This change of wind may as well turn a new page in the history of D


 Wow, I didn't see that coming.

 At very least, just put it on a deprecation schedule. I'm happy (perhaps
 even prefer) to use the alternative approach I've describe if those 2
 issues are addressed in some way.

The funny thing about that is that for the most part, language features which are supposed to be deprecated tend to just stick around instead of getting deprecated, meaning that people keep on using them, and that by the time they're actually deprecated, they'll break that much more code... It's one thing to decide not to make a change becasue we don't want to break code. It's quite another to just keep putting it off to avoid breaking code. That just makes things worse when it finally happens.

I've conceded that I don't mind changing my code, if a satisfactory alternative exists (it doesn't currently). Also, I'd like to have some notice that I need to make some time to change the code, and the opportunity to work it into my schedule. Surely that's not unreasonable. --bcaec54ee84a650f8f04c8645acc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 August 2012 04:31, Jonathan M Davis <span = dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jm= davisProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Wednesday, August 29, 2012 01:13= :15 Manu wrote:<br> &gt; On 28 August 2012 21:52, Andrei Alexandrescu<br> &gt;<br> &gt; &lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org">SeeWebsiteForEmai= l erdani.org</a>&gt;wrote:<br> &gt; &gt; On 8/28/12 8:23 AM, Manu wrote:<br> &gt; &gt;&gt; Well that&#39;s painful for a number of reasons..<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Other than the fact that I need to rewrite a bunch of code,<b= r> &gt; &gt;<br> &gt; &gt; Walter and Kenji think breaking meaningful existing code is an ov= erriding<br> &gt; &gt; concern, and I ended up agreeing with them.<br> &gt; &gt;<br> &gt; &gt; They will look into a solution that keeps your working code worki= ng.<br> &gt; &gt;<br> &gt; &gt; This change of wind may as well turn a new page in the history of= D :o).<br> &gt;<br> &gt; Wow, I didn&#39;t see that coming.<br> &gt;<br> &gt; At very least, just put it on a deprecation schedule. I&#39;m happy (p= erhaps<br> &gt; even prefer) to use the alternative approach I&#39;ve describe if thos= e 2<br> &gt; issues are addressed in some way.<br> <br> </div></div>The funny thing about that is that for the most part, language = features which<br> are supposed to be deprecated tend to just stick around instead of getting<= br> deprecated, meaning that people keep on using them, and that by the time<br=

r> <br> It&#39;s one thing to decide not to make a change becasue we don&#39;t want= to break<br> code. It&#39;s quite another to just keep putting it off to avoid breaking = code.<br> That just makes things worse when it finally happens.<br></blockquote><div>= <br></div><div>I&#39;ve conceded that I don&#39;t mind changing my code, if= a satisfactory alternative exists (it doesn&#39;t currently). Also, I&#39;= d like to have some notice that I need to make some time to change the code= , and the opportunity to work it into my schedule.</div> <div>Surely that&#39;s not unreasonable.</div></div> --bcaec54ee84a650f8f04c8645acc--
Aug 29 2012
prev sibling next sibling parent "Carl Sturtivant" <sturtivant gmail.com> writes:
On Tuesday, 28 August 2012 at 20:33:50 UTC, Carl Sturtivant wrote:
 On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
 On 8/26/2012 4:50 PM, Timon Gehr wrote:
 On 08/27/2012 12:41 AM, Walter Bright wrote:
 The trouble for function pointers, is that any default args 
 would need
 to be part of the type, not the declaration.

They could be made part of the variable declaration.

You mean part of the function pointer variable? Consider what you do with a function pointer - you pass it to someone else. That someone else gets it as a type, not a declaration. I.e. you lose the default argument information, since that is not attached to the type.

I think this is the right behavior too. Default arguments are IMHO just a compact way to write some simply related overloaded functions, e.g. thus: int sum(int x, int y = 1 ) { return x + y; } is just a compact way to write int sum(int x, int y) { return x + y; } int sum(int x) { return sum(x, 1); } and a function pointer refers to a single function, so overloading and default arguments are irrelevant to function pointers. It just so happens that the particularly simple overloading abbreviated by a function definition with default arguments is easily optimized by the compiler with only one function arriving at the linker: the most general one. And that's the one whose address is supplied if the unary & operator is applied to it. So that's the problem with 'int sum(int x, int y = 1 ) ...' --- it's not one function under the interpretation above. So how could we interpret int function(int x, int y = 1) sum; in the above interpretation? What's happening right now is that sum is considered to be a single function pointer, so we discard the default to get the most general function type much like the effect of unary & above. So the trouble with the supposed type 'int function(int x, int y = 1)' is that it is not one type, just as the function sum above is not one function. [Speculation mode starts here.] So what if function pointer declarations with defaults are considered to define several function pointers and not just one. e.g. thus: int function(int x, int y = 1) sum; could be taken by the compiler to mean int function(int x, int y) sum; //all the rest call back the general function pointer int function(int x) sum = function sum(int x) { return sum(x,1); } I haven't explored all of the ramifications of this, but it looks as if it solves quite a few problems without changing the type system, or affecting existing code. And there's a simple model of what's going on: overloading, just generalized slightly. This may not be clean enough or general enough. But the basic point that something like 'int function(int x, int y = 1)' is a sequence of types is worth attention. A declaration using a sequence of types should produce a sequence of function pointers under this interpretation. Exactly how "sequence of types" and "sequence of pointers" should be wrapped up for best effect is then the language design decision to make. There are several other interesting ways to go, some involving getting more general and allowing other kinds of overloading with function pointer sequences, not just the special kind that comes from default arguments, but I'll stop here for now.

Here is an additional implementation possibility for the minimal version where there are no new types. Parameters, e.g.: void fun(int x, int function(int x, int y = 1) fun) { //... j = fun(3); //alerts the compiler //... } could be analogously compiled to behave similarly, because the default arguments are 'nearby'. Here's what the compiler could in effect produce from the above. int fun(int x, int function(int x, int y) fun) { int function(int x) fun = function void(int x) { return fun(x, 1); } //... j = fun(3); //... } i.e. use local variables for the required specialized versions of the function. Of course then the question of "how near is nearby?" needs a design decision.
Aug 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 29, 2012 12:40:45 Manu wrote:
 I've conceded that I don't mind changing my code, if a satisfactory
 alternative exists (it doesn't currently). Also, I'd like to have some
 notice that I need to make some time to change the code, and the
 opportunity to work it into my schedule.
 Surely that's not unreasonable.

Ideally, something which is going to be deprecated is first scheduled for deprecation (and marked as such in both the changelog and documentation) and then later deprecated, giving programmer's time to change their code first. It almost always works that way with druntime and Phobos, but I don't think that we necessarily do as good a job with the compiler. Frequently the situation is that people on the newsgroup know fullwell that a feature is going to be deprecated (e.g. delete), but that's not well communicated outside of this group, and for some reason, the to-be-deprecated items just don't get deprecated even though it's been definitively decided that they will be at some point. In this particular case, it was viewed as a bug fix, and bug fixes break code all the time (especially accepts-invalid bugs), so no effort was made to indicate that a feature was going away (i.e. it was viewed as feature being fixed rather than a feature going away, so no notification beyond the bugfix in the changelog was given). Obviously, this was not handled in the best way, as this thread has shown. But stuff that's actually viewed as being deprecated generally is handled much better. - Jonathan M Davis
Aug 29 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Wednesday, 29 August 2012 at 07:00:06 UTC, Marco Leise wrote:
 Am Mon, 27 Aug 2012 19:46:57 +0200
 schrieb "foobar" <foo bar.com>:

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

Properties are currently implemented as "strip off the and continue". They are mapped to storage class bit flags, like the others with no special code paths or data structures in place.

I was talking about complexity added to _the language_ and its syntax - the part exposed to the user. I did not mean to imply anything about the compiler implementation of it. If what you say is true, it just shows that those features such as pure shouldn't have got the prefix in the first place. Anyway, my main point was: a. There already is popular demand for metadata. b. We already have some of the desired syntax for it in the language c. Once the facility is fully implemented and supports user defined annotations it could also be leveraged to implement default arguments as well.
Aug 29 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 28 Aug 2012 04:57:53 -0400, Don Clugston <dac nospam.com> wrote:

 On 27/08/12 16:16, Steven Schveighoffer wrote:
 On Sun, 26 Aug 2012 18:26:40 -0400, Manu <turkeyman gmail.com> 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.

OK, I've read all the posts on this, and this is what I think would solve the problem: 1. default parameters are part of the function pointer type, because a function pointer has a type. 2. The mangled name of the function that is assigned to that function pointer does *not* have default parameters mangled in. Only the function pointer type has them. 3. Since the default parameters are part of the type, but not defined by the function it points to, you can use interchangeably functions of the same type which define default parameters or not (or define different ones). The default parameters follow the function pointer variable.

This sounds like sloppy thinking. I _think_ what you are saying is that there should be implicit conversions from one function pointer type, to any other that has the same basic declaration, but different default arguments. But then you get problems with IFTI. void foo( void function(int x), double) {} void foo( void function(int x), int) {} void function(int x = 10) bar; foo(bar, 5); // fails -- ambiguous. Both overloads match with implicit conversions.

First, I don't see IFTI anywhere in there. Second, why is this a problem? We already have oddities in terms of how implicitly converting one argument makes the interpretation of non-ambiguous arguments ambiguous. I don't think it's sloppy, my logic is: we can already (I think) do this in library code, so why is it impossible for the compiler to figure out?
 But really, it seems to me that this whole feature is just syntax sugar  
 for one special case of currying.

Probably. But it is what it is -- a poorly implemented/designed language feature. In most cases, we don't simply drop them without giving a replacement. Examples: octal literals, complex numbers, scope classes. -Steve
Aug 29 2012
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
OK. I have finished working to implement it as a new pull request.
https://github.com/D-Programming-Language/dmd/pull/1102

It contains several test suites that indicate which case is supported or not.
https://github.com/D-Programming-Language/dmd/pull/1102/files#L6R1

Regards.

Kenji Hara

2012/8/29 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 On 8/28/12 8:23 AM, Manu wrote:
 Well that's painful for a number of reasons..

 Other than the fact that I need to rewrite a bunch of code,

Walter and Kenji think breaking meaningful existing code is an overriding concern, and I ended up agreeing with them. They will look into a solution that keeps your working code working. This change of wind may as well turn a new page in the history of D :o). Andrei

Sep 06 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
--bcaec54fb81a08088704c97cbd2f
Content-Type: text/plain; charset=UTF-8

On 6 September 2012 12:15, kenji hara <k.hara.pg gmail.com> wrote:

 OK. I have finished working to implement it as a new pull request.
 https://github.com/D-Programming-Language/dmd/pull/1102

 It contains several test suites that indicate which case is supported or
 not.
 https://github.com/D-Programming-Language/dmd/pull/1102/files#L6R1

Awesome, thanks for this! How far off is 2.61 likely to be? --bcaec54fb81a08088704c97cbd2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 September 2012 12:15, kenji hara <span dir= =3D"ltr">&lt;<a href=3D"mailto:k.hara.pg gmail.com" target=3D"_blank">k.har= a.pg gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> OK. I have finished working to implement it as a new pull request.<br> <a href=3D"https://github.com/D-Programming-Language/dmd/pull/1102" target= =3D"_blank">https://github.com/D-Programming-Language/dmd/pull/1102</a><br> <br> It contains several test suites that indicate which case is supported or no= t.<br> <a href=3D"https://github.com/D-Programming-Language/dmd/pull/1102/files#L6= R1" target=3D"_blank">https://github.com/D-Programming-Language/dmd/pull/11= 02/files#L6R1</a></blockquote><div><br></div><div>Awesome, thanks for this!= </div> <div>How far off is 2.61 likely to be?</div></div> --bcaec54fb81a08088704c97cbd2f--
Sep 12 2012