DIP54 : revamp of Phobos tuple types

[Timon Gehr]

On 12/30/2013 03:58 AM, Dicebot wrote:
> 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).

The spec is poor here, but it _still_ implies that the type of an 
'expression tuple' is the corresponding 'type tuple'.

http://dlang.org/tuple.html

In any case, if something is to be fixed here it is the spec. It seems 
not formal enough if there can be any doubt that this is not intended 
behaviour. (Many language features are specified by example rather than 
by general rules.)

> It behaves as if one is the instance of the other but is more
> of coincidence than intended rule.
> ...

I'm sorry, but this is nonsense. The list of type / type of list 
confusion is not a rule that gets accidentally implemented in a compiler.

> I also remember Andrei mentioning in one of tuple threads that this
> relation is not supposed to be valid in general

Unlikely. Andrei is considered a D expert.

> 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.

No, it is not.

> 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.
> ...

This.

>> 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.

It's critical if you want to support the real opSlice.