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

[rikki cattermole]

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.



Signatures is a language feature that originates from the ML family of 
languages.

It is in my opinion the best companion to meta-programming and CTFE you 
could ever have.

 From a runtime perspective it would be a vtable, with method bodies 
being able to be patched on top of the implementation type (struct or 
class) so that the interface (signature) could adapt to the 
implementation silently.

At compile time it would act as a type verifier like isInputRange and 
friends.

It could infer its template instance type from an implementation with 
automatic binding named parameters to types and constants of the 
implementation. Separating the interface elements like the ElementType 
of an input range from the implementation and allowing some information 
transfer so it could be passed around at runtime.

The design elements from DIP 1020 that would have allowed for this are 
not wanted by the community or by Walter.

There is nothing I can do without butchering this concept to make it as 
powerful as it could have been.



"It is possible to commit no mistakes and still lose. That is not a 
weakness. That is life." - Jean-Luc Picard