View mode: basic / threaded / horizontal-split · Log in · Help
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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;
> }
>
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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?
August 27, 2012
Re: Function pointers/delegates default args were stealth removed?
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.
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home