DIP54 : revamp of Phobos tuple types

Dicebot public at dicebot.lv
Sun Dec 29 18:58:20 PST 2013


On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
> What would be an example of code that you consider to be broken?
> (TemplateArgumentList!(int, double) is a valid type and 
> TemplateArgumentList!(1, 2.0) is a value of that type.)

Stuff that relies that, for example, that `is(TypeTuple!(int, 
double) == typeof(TypeTuple!(42, 2.0)))`. There is no place in 
specification that defines / guarantees it or even define tuple 
as a valid type entity (or, to be precise, I have been looking 
for one and failed to find the mention). It behaves as if one is 
the instance of the other but is more of coincidence than 
intended rule.

I also remember Andrei mentioning in one of tuple threads that 
this relation is not supposed to be valid in general but it is 
very hard to find exact comment right now. Andrei can you please 
either confirm this or call me wrong? :)

>> Only thing I have difficulties with right now is defining 
>> static opSlice
>> for Pack so that it may return another Pack instead of raw 
>> list. But
>> that looks like compiler defect and should work as far as I 
>> read the
>> spec.
>
> This problem is also present in std.typecons.Tuple. Where does 
> the spec claim that static opSlice can work for this use case?

It is in line with general rule of opXXX for structs working as 
syntax rewrite. Spec needs to claim it is not legal in that 
regard, not other way around ;) But for this to be helpful it 
needs to turn indexes into template arguments and this will be 
enhancement request for sure.

> I find the fact that alias this is required for implementation 
> of either Tuple or Pack to be an annoying language limitation.

Me too. Maybe it should be addressed in general by defining 
template-argument opXXX - than it is subject of own DIP indeed. 
It is not critical for this DIP implementation so I did not think 
about it in details but it can make implementation much more 
hygienic.


More information about the Digitalmars-d mailing list