On Sat, Oct 6, 2012 at 8:01 PM, Arlen <arlen.ng@gmx.com> wrote:
> 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...) { }

Double-stage templates (which reminds me of rocket science :)  )

template Merge(A...)
{
    template With(B...)
    { }
}


Usage:

Merge!(int,double,string).With!(double,byte)

On 07-Oct-12 11:23, Philippe Sigaud wrote:
> On Sat, Oct 6, 2012 at 8:01 PM, Arlen <arlen.ng@gmx.com> wrote:
>> 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...) { }
>
> Double-stage templates (which reminds me of rocket science :)  )
>
> template Merge(A...)
> {
>      template With(B...)
>      { }
> }
>
>
> Usage:
>
> Merge!(int,double,string).With!(double,byte)
>
Rox!

-- 
Dmitry Olshansky

On Sun, Oct 7, 2012 at 2:23 AM, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
>
> Double-stage templates (which reminds me of rocket science :)  )
>
> template Merge(A...)
> {
>     template With(B...)
>     { }
> }
>
>
> Usage:
>
> Merge!(int,double,string).With!(double,byte)

I can live with that, but, as I explained before, TypeTuples cause code duplication in certain cases because they force 'alias' to be used in the signature of the metafunctions.

And how would you return a multi-dimensional TypeTuple?  The result of certain metafunctions are multi-dimensional.  For example, Permutations and Combinations will return multi-dimensional "containers".

http://arlen.github.com/phobos/std_typelist2.html#Permutations

On Sunday, October 07, 2012 22:57:33 Arlen wrote:
> I can live with that, but, as I explained before, TypeTuples cause code duplication in certain cases because they force 'alias' to be used in the signature of the metafunctions.
> 
> And how would you return a multi-dimensional TypeTuple?  The result of certain metafunctions are multi-dimensional.  For example, Permutations and Combinations will return multi-dimensional "containers".
> 
> http://arlen.github.com/phobos/std_typelist2.html#Permutations

While this sort of function might be useful from time to time, how often is it actually, realistically needed? Certainly, I'd argue that it's rare enough that having a slightly more complicated solution specifically for it makes more sense than adding a whole new abstraction to the standard library.

Adding something like TypeList on top of TypeTuple is generally overkill and overcomplicates things. TypeTuple will do almost everything that TypeList can. The question then is how to make TypeTuple do the parts that it can't currently do or how to provide a reasonable, alternate solution for those rare circumstances. Maybe a multi-dimensional wrapper for TypeTuple would be in order to handle those cases?

Regardless, we previously decided that TypeList was unnecessary code duplication and an unnecessary cognitive burden. Everything you add to the standard library has a cost, even if it's valuable in and of itself, and adding something very similar to something else which is already there is that much worse, because then you have to understand the differences and constantly explain them to those who don't know. So, we're not adding TypeList.

While I sympathize with your desire to get some of the functionality that TypeList provides and TypeTuple doesn't, please work with us to improve upon TypeTuple rather than trying to add something to Phobos that does almost the same thing as TypeTuple. In most cases, it's simply a matter of adding the appropriate templates to gain TypeList-like functionality on top of TypeTuple rather than adding TypeList, and we've even recently added (post-2.060) some of those templates to std.typetuple, thereby improving what can be done with std.typetuple.

- Jonathan M Davis

On Sun, Oct 7, 2012 at 11:16 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
> While this sort of function might be useful from time to time, how often is it actually, realistically needed? Certainly, I'd argue that it's rare enough that having a slightly more complicated solution specifically for it makes more sense than adding a whole new abstraction to the standard library.
>

That particular metafunction may not have a lot of usage, I agree, but I was trying to make the point that TypeTuples do not support multi-dimensions.  For example, in the Boost.units library that I'm porting to D, multi-dimensional typelist are common.  To solve algebraic equations of types can require matrices, and to implement a matrix you'll need a typelist of typelist.


>
>  So, we're not adding TypeList.
>

Oh, I was aware that a decision had already been made.  I thought it was an open issue.


> While I sympathize with your desire to get some of the functionality that TypeList provides and TypeTuple doesn't, please work with us to improve upon TypeTuple rather than trying to add something to Phobos that does almost the same thing as TypeTuple. In most cases, it's simply a matter of adding the appropriate templates to gain TypeList-like functionality on top of TypeTuple rather than adding TypeList, and we've even recently added (post-2.060) some of those templates to std.typetuple, thereby improving what can be done with std.typetuple.
>
> - Jonathan M Davis

Since TypeList is out of the question, I need to figure out what to do with the units library first.

On Monday, October 08, 2012 00:14:04 Arlen wrote:
> >  So, we're not adding TypeList.
> 
> Oh, I was aware that a decision had already been made.  I thought it was an open issue.

It was decided the last time that std.typelist was brought up. Basically, TypeList doesn't provide enough over TypeTuple to be worth it, and we don't want two different abstractions for essentially the same thing.

> Since TypeList is out of the question, I need to figure out what to do with the units library first.

Well, there may very well be cases that are more work due to the lack of TypeList, but it should be possible to make them work with TypeTuple, though it could mean adding more functionality to std.typetuple to make it work.

- Jonathan M Davis