On 14/09/2019 7:48 AM, jmh530 wrote:
> On Friday, 13 September 2019 at 18:29:56 UTC, rikki cattermole wrote:
>> On 14/09/2019 5:49 AM, M.M. wrote:
>>> I wish they could find the energy to come up with a new DIP..
>> No point on my end.
>>
>> I may as well explain why I created DIP 1020 officially now that it is dead.
>>
>> The reason is signatures.
>> [snip]
> 
> I feel like this is an argument you should have made much earlier...like...in the DIP...

I felt it was inappropriate to state such possibilities in the DIP or in the review thread(s) as it may never came to pass.

As per the spirit of the DIP process, a DIP by itself should function as a whole and not rely on future potential DIP's for its merit. Examples of this can be seen in DIP 1019's review threads.

I consider DIP 1020 to have done that. Served its use cases that were numerous without needing a potential DIP to the future to describe its potential. However I doubt many people would agree with my belief in that.

Anyway the concept of signatures that I have, while spending 2 years on it up to now, I had concluded before DIP 1020 was created that the only way to implement it was to break it up into much smaller design problems and named arguments happened to fit a key part of it.

It would have been equivalent of adding a class system to D. That is not a small design problem and could of easily damaged the language if done wrong.

Perhaps it would have been possible 10 years ago, but D is a production language. It had a high chance of failure.

On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:
> I'm going to be blunt, so shields up!
>
> For DIP 1020 and DIP 1019, I keep trying to nudge things in the direction of a better design:
>
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627
>
> All to no avail. It pains me a great deal to see all this effort and discussion going down the drain on designs that are both more complex and inadequate. The authors have exhibited little or no interest in either adopting my suggestions or explaining why theirs are better.
>
> Andrei and Atila have tried as well.
>
> This has gone on long enough. DIP 1019 and 1020 are not going to be approved.
>
> (It is clear that a lot of time was spend on the DIPs, and they are well written and presented. The authors should be proud of them. It's just that we have a better design.)

That is fair. But keep in mind there is a difference here. DIP 1019/1020 are _ready_, meaning they can start to be implemented once approved. OTOH, the better design is still just an idea, and no one seems to be willing to take on the task to write a DIP for it.

Is it a good idea to stall a useful feature indefinitely because there is some potential better design?

(Yes, I'm bitter and biased, but I still this is a legitimate question to ask.).

On 16/09/2019 2:32 AM, Yuxuan Shui wrote:
> On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:
>> I'm going to be blunt, so shields up!
>>
>> For DIP 1020 and DIP 1019, I keep trying to nudge things in the direction of a better design:
>>
>> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627 
>>
>>
>> All to no avail. It pains me a great deal to see all this effort and discussion going down the drain on designs that are both more complex and inadequate. The authors have exhibited little or no interest in either adopting my suggestions or explaining why theirs are better.
>>
>> Andrei and Atila have tried as well.
>>
>> This has gone on long enough. DIP 1019 and 1020 are not going to be approved.
>>
>> (It is clear that a lot of time was spend on the DIPs, and they are well written and presented. The authors should be proud of them. It's just that we have a better design.)
> 
> That is fair. But keep in mind there is a difference here. DIP 1019/1020 are _ready_, meaning they can start to be implemented once approved. OTOH, the better design is still just an idea, and no one seems to be willing to take on the task to write a DIP for it.
> 
> Is it a good idea to stall a useful feature indefinitely because there is some potential better design?
> 
> (Yes, I'm bitter and biased, but I still this is a legitimate question to ask.).

Walter has begun working on it as stated on his Twitter account[0].

I have given him feedback to help improve it via Twitter. It has a long way to go given the feedback the DIPs 1019+1020 received (which IMHO has set a precedent for what it needs to include).

[0] https://twitter.com/WalterBright/status/1173165009926443009

On Sunday, 15 September 2019 at 14:50:06 UTC, rikki cattermole wrote:
> On 16/09/2019 2:32 AM, Yuxuan Shui wrote:
>> [...]
>
> Walter has begun working on it as stated on his Twitter account[0].
>
> I have given him feedback to help improve it via Twitter. It has a long way to go given the feedback the DIPs 1019+1020 received (which IMHO has set a precedent for what it needs to include).
>
> [0] https://twitter.com/WalterBright/status/1173165009926443009

I'm always one step behind, aren't I.

That is great news.

On Sunday, 15 September 2019 at 14:50:06 UTC, rikki cattermole wrote:
> On 16/09/2019 2:32 AM, Yuxuan Shui wrote:
>> [...]
>
> Walter has begun working on it as stated on his Twitter account[0].
>
> I have given him feedback to help improve it via Twitter. It has a long way to go given the feedback the DIPs 1019+1020 received (which IMHO has set a precedent for what it needs to include).
>
> [0] https://twitter.com/WalterBright/status/1173165009926443009

Is Walter's approach compatible with your idea of to signatures?

On 9/15/2019 7:50 AM, rikki cattermole wrote:
> Walter has begun working on it as stated on his Twitter account[0].
> 
> I have given him feedback to help improve it via Twitter. It has a long way to go given the feedback the DIPs 1019+1020 received (which IMHO has set a precedent for what it needs to include).
> 
> [0] https://twitter.com/WalterBright/status/1173165009926443009

Thanks for the feedback!

(Technical feedback should go on the github page, not twitter.)

On 16/09/2019 6:34 AM, M.M. wrote:
> On Sunday, 15 September 2019 at 14:50:06 UTC, rikki cattermole wrote:
>> On 16/09/2019 2:32 AM, Yuxuan Shui wrote:
>>> [...]
>>
>> Walter has begun working on it as stated on his Twitter account[0].
>>
>> I have given him feedback to help improve it via Twitter. It has a long way to go given the feedback the DIPs 1019+1020 received (which IMHO has set a precedent for what it needs to include).
>>
>> [0] https://twitter.com/WalterBright/status/1173165009926443009
> 
> Is Walter's approach compatible with your idea of to signatures?

Its compatible just like how a bool is an integer is compatible to signatures.

Basically there needs to be a way to represent properties (as in members) on the type (types/constants) that can then be set by the user (for i.e. heap storage) and inferred by the implementation type i.e.

static assert(InputRange(Map(...)).ElementType == Map.ElementType);
static assert(InputRange(Map(...)) == InputRange(Filter(...)));

struct Map {
	alias ElementType = int;
}

struct Filter {
	alias ElementType = int;
}

signature InputRange(@named ElementType) {
	...
}

The above ignores things like memory management but it does give a basic overview of why Walter's design doesn't do anything for my design of signatures.

On Monday, 16 September 2019 at 11:32:35 UTC, rikki cattermole wrote:
> [...]
>
> The above ignores things like memory management but it does give a basic overview of why Walter's design doesn't do anything for my design of signatures.

But if I understand it correctly, Walter's design also does not stand in bringing a design of signatures?

On 17/09/2019 8:38 PM, M.M. wrote:
> On Monday, 16 September 2019 at 11:32:35 UTC, rikki cattermole wrote:
>> [...]
>>
>> The above ignores things like memory management but it does give a basic overview of why Walter's design doesn't do anything for my design of signatures.
> 
> But if I understand it correctly, Walter's design also does not stand in bringing a design of signatures?

It does not no.

My current design which I created as a backup to DIP1020 which supports his, I do not believe fits in with the current design of signatures.

I.e.

struct Foo(public T) {
}

static asssert(Foo!(T: int).T == int);

On Tuesday, 17 September 2019 at 12:37:50 UTC, rikki cattermole wrote:
> [snip]
>
> It does not no.
>
> My current design which I created as a backup to DIP1020 which supports his, I do not believe fits in with the current design of signatures.
>
> I.e.
>
> struct Foo(public T) {
> }
>
> static asssert(Foo!(T: int).T == int);

I think I'm starting to understand your signatures idea from this.

That being said, I think this would be a lot simpler if types were first class citizens. If they were, then you could easily return types from functions. So instead of your Foo above, you could have

struct Foo(T) {
    type T() {
        return T;
    }
}

You could write mixins to automatically generate those functions pretty easily as a first step.

Above you have an example with

> signature InputRange(@named ElementType) {
> 	...
> }

But I think this would have the same issue as your @named syntax.