Closed ChristianMurphy closed 4 years ago
/cc @remcohaszing
This looks cool.
But I’m not sure if I’m up to speed the implementation details. Are these assumptions correct?
with #92
// ..
.use<A, B, C>([pluginA, pluginB, pluginC]) // Matches types in the same order. Repetition required, even if types are the same.
// ..
with #96 (this)
// ..
.use<A, R>([pluginA, pluginB, pluginC]) // `A` is matched with pluginA and `R` with pluginB and pluginC
// ..
Excellent question
In both cases the goal is to support type inferencing.
.use([pluginA, [pluginB, settingsB], presetC])
should work.
Explicitly showing the types for #92
.use<SettingsA, SettingsB, SettingsC>([pluginA, [pluginB, settingsB], presetC])
with the limitation that it would no longer check after 10 items are added to use
.
Explicitly showing the types for #96
.use<SettingsA, PluggableList<SettingsB, PluggableList<SettingsC, []>>>([pluginA, [pluginB, settingsB], presetC])
where PluggableList is a recursive type, which types a single plugin setting, and recurses to support any other plugins' settings. The advantage being that it should support any number of parameters passed.
What is blocking this?
getting the typing to work 🙂 closing this for now, will revisit later if there is interest
alternative to #92
This approaches the typing from the perspective of tail recursion. Each call to
PluggableList
will handle the type of the first/head item of the list, the it will recurse for all other items in the list.TODO: