August 27, 2012
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
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
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
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
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
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
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
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
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
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.