On Tuesday, 24 May 2016 at 01:33:40 UTC, Adam D. Ruppe wrote:
On Monday, 23 May 2016 at 20:08:11 UTC, Daniel N wrote:
This pull request just removes an intentional restriction and make this feature more easily accessible for meta-programming, so that not everyone has to reinvent the wheel in their own libraries.

Soooo I'm actually not entirely convinced on that change. Parameter names should *not* be part of a function pointer or delegate type

From an end-user perspective I find it reasonable to expect that an API which takes lambda:s works consistently for both below examples. i.e. if we support one we should support the other.

[1] fun!(     x  => y)
[2] fun!((int x) => y)

Currently I just copy/paste the fix to ParameterIdentifierTuple everywhere as the needed primitives already exist.

Removing the already existing primitives now is imho too late, as it breaks code, which sometimes is OK, but this time there's no clear solution how to rewrite the broken code.

Unfinished Library based Named-parameters proof-of-concept:
(yes, I know. It needs to be updated to handle case [2])

/vote open floodgates for introspection, capitalizing on the strengths of D.

Reply via email to