digitalmars.D - Re: Preliminary submission - std.rational and std.typelist
- "Arlen" <arlen.ng gmx.com> Oct 06 2012
- "David Nadlinger" <see klickverbot.at> Oct 06 2012
I'm not sure if TypeTuples work well when doing things like dimensional analysis. For example, if you have two TypeTuples, A and B, what would the signature of the metafunction to merge the two look like? template Merge(A, B) { } won't work, and neither will template Merge(alias A, alias B) { } and you certainly can't do something like template Merge(AB...) { } Arlen ----- Original Message ----- From: Jonathan M Davis Sent: 10/06/12 12:52 PM To: digitalmars.D Subject: Re: Preliminary submission - std.rational and std.typelist On Saturday, October 06, 2012 19:03:39 Arlen wrote:I wasn't aware that we already had std.typelist module in Phobos until I was ready to submit my work. I suppose the work was abandoned or it was never finalized? There are differences in typelist2.d and typelist.d, though.
It needs to be removed. It's not even compiled in. std.typetuple is what we use. I would suggest looking at adding further functionality to it rather than trying to create anything based on type lists. TypeTuples can do the same things and are actually more flexible. - Jonathan M Davis
Oct 06 2012
On Saturday, 6 October 2012 at 18:13:19 UTC, Arlen wrote:For example, if you have two TypeTuples, A and B, what would the signature of the metafunction to merge the two look like?
In my experience, these cases occur a lot less frequently than one might think when first encountering the problem. The solution I usually go for is to just define a ConfinedTuple (or something like that) template: --- template ConfinedTuple(T...) { alias T Tuple; } template SomeAlgorithm(alias A, alias B) {} --- Then, call that one algorithm using SomeAlgorithm!(ConfinedTuple!A, ConfinedTuple!B). At least to me, it seems to be the better tradeoff compared to re-implementing all the TypeTuple functionality for another compile-time tuple type. David
Oct 06 2012