http://wiki.dlang.org/DIP30

As usual, go for simplicity, reduce the number of entity the
language define.

Feel free to destroy.

On Wednesday, 13 March 2013 at 18:00:54 UTC, deadalnix wrote:
> http://wiki.dlang.org/DIP30
>
> As usual, go for simplicity, reduce the number of entity the
> language define.
>
> Feel free to destroy.

From "Fully typed delegates": "Delegate's context is assumed to be of type void*. However, it can be specified as a type after the parameter list ".

This does not look like the best idea: 1) context pointer may point to function frame with several different objects, 2) there are no evidences in th DIP about which problems are solved by ability to append explicit type of context pointer.

From " UFCS as delegates": example with function foo(ref uint a) raises concern about ABI implementation. Currently context pointer is passed through RDI and arguments are passed differently. There would be a problem with functions like foo() which do not know from where to take an argument - are they called directly or like a closure?

Frankly, I see this simpler: delegate = function pointer + data pointer, so they should follow language rules (especially regarding qualifiers).

Currently this works:

struct S
{
    immutable int i;
    void bar() {}
    int foo() immutable
    {
        //bar();
        (&bar)();
        return i;
    }
}

I think that delegate call should be treated as a function call with extra parameter. If .funcptr is deduced to have qualifier X, than delegate call should be permitted only if explicit regular function call with X qualifier is permitted in that scope. Similar should happen with .ptr.

On 03/13/2013 07:00 PM, deadalnix wrote:
> http://wiki.dlang.org/DIP30
>
> As usual, go for simplicity, reduce the number of entity the
> language define.
>
> Feel free to destroy.

It's quite pretty.

But:

1. Removes optional parens for UFCS
2. Syntactic confusion of ref applying to return value and ref applying to context. Rules are insufficiently specified.
3. Misses the load mutable-context delegate from const-qualified type case.
4. typeof(dg.ptr), typeof(dg.funcptr) ? (quite obvious what you want, but missing)

Also: You will have to change the ABI in order to unify UFCS with methods, because the implicit 'this' pointer is passed as the last argument for methods IIRC.

On Wednesday, 13 March 2013 at 18:54:29 UTC, Maxim Fomin wrote:
> From "Fully typed delegates": "Delegate's context is assumed to be of type void*. However, it can be specified as a type after the parameter list ".
>

Pointer already cast to void* so that isn't really new. ref are pointer behind the hood.

This is necessary as the context type is especially important for value types, not really for reference/pointers.

> This does not look like the best idea: 1) context pointer may point to function frame with several different objects, 2) there are no evidences in th DIP about which problems are solved by ability to append explicit type of context pointer.
>

1) It is explained : context is a pointer to a tuple.
2) It does allow value type as context, which in return allow to unify many construct into delegates. It also solve the qualifier transitivity problem.

> From " UFCS as delegates": example with function foo(ref uint a) raises concern about ABI implementation. Currently context pointer is passed through RDI and arguments are passed differently. There would be a problem with functions like foo() which do not know from where to take an argument - are they called directly or like a closure?
>

I don't think ABI should be part of D spec. Or should it ?

Anyway, I don't see any reason to have all kind of different ABI for function call, and this is a good opportunity to unify everything using the context as a regular, first argument.

> Frankly, I see this simpler: delegate = function pointer + data pointer, so they should follow language rules (especially regarding qualifiers).
>

It is a tempting idea, but do not work. Consider :

void delegate() immutable a;
const void delegate() b = a;

This would be forbidden as covariance of function parameters and transitivity act in opposite directions.

On Wednesday, 13 March 2013 at 20:43:13 UTC, Timon Gehr wrote:
> On 03/13/2013 07:00 PM, deadalnix wrote:
>> http://wiki.dlang.org/DIP30
>>
>> As usual, go for simplicity, reduce the number of entity the
>> language define.
>>
>> Feel free to destroy.
>
> It's quite pretty.
>
> But:
>
> 1. Removes optional parens for UFCS

It is still possible to have optional () in many cases. For instance in chained calls. It have the big advantage to unify the optional () for all callable (and we only have 2 of them now).

> 2. Syntactic confusion of ref applying to return value and ref applying to context. Rules are insufficiently specified.

Yeah, the idea is basically to differentiate prefix and postfix qualifiers. Note that this is already ambiguous in many cases in the current grammar.

> 3. Misses the load mutable-context delegate from const-qualified type case.

Yeah, I clearly have to edit the DIP to explain that.

> 4. typeof(dg.ptr), typeof(dg.funcptr) ? (quite obvious what you want, but missing)
>
> Also: You will have to change the ABI in order to unify UFCS with methods, because the implicit 'this' pointer is passed as the last argument for methods IIRC.

I don't see the point of having a different ABI in the first place, and am not sure if ABI should be specified here.

2013/3/14 deadalnix <deadalnix@gmail.com>
>
> It is a tempting idea, but do not work. Consider :
>
> void delegate() immutable a;
> const void delegate() b = a;
>
> This would be forbidden as covariance of function parameters and transitivity act in opposite directions.
>

You are misunderstanding about delegate type syntax and transitivity.

1. This qualifier for delegate type should be added after parameter types.

const void delegate() b;   // bad, typeof(b) == const(void deelgate())
void delegate() const b;   // good, b can hold const method

2. A delegate which has immutable context cannot implicitly convertible to const context delegate.

In general, if a delegate can implicitly convertible to another, there should be _contravariance_ of parameter types.

void delegate() immutable a;
void delegate() const b;
b = a;  // bad
a = b;  // good

Kenji Hara

On Thursday, 14 March 2013 at 03:45:39 UTC, kenji hara wrote:
> 2013/3/14 deadalnix <deadalnix@gmail.com>
>>
>> It is a tempting idea, but do not work. Consider :
>>
>> void delegate() immutable a;
>> const void delegate() b = a;
>>
>> This would be forbidden as covariance of function parameters and
>> transitivity act in opposite directions.
>>
>
> You are misunderstanding about delegate type syntax and transitivity.
>
> 1. This qualifier for delegate type should be added after parameter types.
>
> const void delegate() b;   // bad, typeof(b) == const(void deelgate())
> void delegate() const b;   // good, b can hold const method
>

After or before don't change anything here as type qualifier are transitives. It means that a const delegate must have a const context. Or, in code :

static assert(is(const delegate() == const delegate() const)); // Pass

> 2. A delegate which has immutable context cannot implicitly convertible to
> const context delegate.
>
> In general, if a delegate can implicitly convertible to another, there
> should be _contravariance_ of parameter types.
>
> void delegate() immutable a;
> void delegate() const b;
> b = a;  // bad
> a = b;  // good
>

As showed above, this is equivalent to my sample code in the previous post, and it does break transitivity.

void delegate() const b; // Context of b is const (ie mutable or immutable).
void delegate() immutable a; // Context of a is immutable
a = b; // a now contains a reference to possibly mutable data considered as immutable by the type system.

This is *VERY* wrong.

On Thursday, 14 March 2013 at 03:12:21 UTC, deadalnix wrote:
>> From " UFCS as delegates": example with function foo(ref uint a) raises concern about ABI implementation. Currently context pointer is passed through RDI and arguments are passed differently. There would be a problem with functions like foo() which do not know from where to take an argument - are they called directly or like a closure?
>>
>
> I don't think ABI should be part of D spec. Or should it ?
>
> Anyway, I don't see any reason to have all kind of different ABI for function call, and this is a good opportunity to unify everything using the context as a regular, first argument.

ABI, at least partly, is and should be part of the spec. Otherwise it has some of the C++ problems. And the point was not about ABI in a sense of adding piece of information to chapter in dlang.org, but about implementing compiler. I am not enthusiastic about most DIPs presented recently because 1) without Walter and Andrei approval 2) without somebody willing to implement it, DIP turns to be a paper intellect exercise and corresponding ideas defence in the forum.

>> Frankly, I see this simpler: delegate = function pointer + data pointer, so they should follow language rules (especially regarding qualifiers).
>>
>
> It is a tempting idea, but do not work. Consider :
>
> void delegate() immutable a;
> const void delegate() b = a;
>
> This would be forbidden as covariance of function parameters and transitivity act in opposite directions.

The problem is that there is 1 qualifier in current syntax and two underlying objects.

On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
> On Thursday, 14 March 2013 at 03:12:21 UTC, deadalnix wrote:
>>> From " UFCS as delegates": example with function foo(ref uint a) raises concern about ABI implementation. Currently context pointer is passed through RDI and arguments are passed differently. There would be a problem with functions like foo() which do not know from where to take an argument - are they called directly or like a closure?
>>>
>>
>> I don't think ABI should be part of D spec. Or should it ?
>>
>> Anyway, I don't see any reason to have all kind of different ABI for function call, and this is a good opportunity to unify everything using the context as a regular, first argument.
>
> ABI, at least partly, is and should be part of the spec. Otherwise it has some of the C++ problems. And the point was not about ABI in a sense of adding piece of information to chapter in dlang.org, but about implementing compiler. I am not enthusiastic about most DIPs presented recently because 1) without Walter and Andrei approval 2) without somebody willing to implement it, DIP turns to be a paper intellect exercise and corresponding ideas defence in the forum.
>

Timon Gehr and I are working on compiler. This isn't intellectual masturbation.

As of ABI, it is right now insufficiently defined to have a situation different than C++'s.

> The problem is that there is 1 qualifier in current syntax and two underlying objects.

Exactly. And theses are using different (and opposite) rules for implicit casts.

On Thursday, 14 March 2013 at 05:29:25 UTC, deadalnix wrote:
> On Thursday, 14 March 2013 at 05:12:51 UTC, Maxim Fomin wrote:
>> ABI, at least partly, is and should be part of the spec. Otherwise it has some of the C++ problems. And the point was not about ABI in a sense of adding piece of information to chapter in dlang.org, but about implementing compiler. I am not enthusiastic about most DIPs presented recently because 1) without Walter and Andrei approval 2) without somebody willing to implement it, DIP turns to be a paper intellect exercise and corresponding ideas defence in the forum.
>>
>
> Timon Gehr and I are working on compiler. This isn't intellectual masturbation.

And without significant usage it is a coding exercise or NIH syndrome. What is good in the compiler (brand new frontend?) relative to gdc/ldc/dmd? Why somebody would switch to it?

> As of ABI, it is right now insufficiently defined to have a situation different than C++'s.

Yes, and this is a problem. But at least it does exists and covers some aspects.

>> The problem is that there is 1 qualifier in current syntax and two underlying objects.
>
> Exactly. And theses are using different (and opposite) rules for implicit casts.

The perhaps should we move DIP in that direction too?