DIP 1020--Named Parameters--Community Review Round 2

[rikki cattermole]

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.