Thoughts on possible tuple semantics

Dicebot public at dicebot.lv
Wed Aug 21 10:18:16 PDT 2013


On Wednesday, 21 August 2013 at 16:53:12 UTC, Meta wrote:
> ...

Thanks for detailed response! :)

> On Wednesday, 21 August 2013 at 15:22:59 UTC, Dicebot wrote:
>>    - Template argument sequence: may contain anything that is 
>> legal template argument.
>
> One thing I'd like to know. If we're at the point where we're 
> discussing possible breaking changes to the language anyway, 
> why is it so important that these tuples behave exactly like 
> template argument lists? How important is it to be able to 
> include both types AND values within the same tuple outside of 
> variadic templates? I don't know if I've ever seen a use case 
> for this.

There is a single huge use case - all templates :) If f we don't 
provide built-in way to express parameters accepted by templates, 
TypeTuple will appear again, because some way to keep and 
manipulate those parameters is a cornerstone for generic 
programming. Just count how many times template variadic 
parameters get sliced (and then aliased or passed to other 
template) in Phobos.

>>    - Value tuple or simply "tuple": may contain any values, 
>> including run-time
>>    values. Value storage location is not defined.
>
> Are you implying that the address of a tuple cannot be taken?

Yes.

>> Mixed template argument sequences are considered types too, 
>> but special one. Those
>> types can be aliased or passed to templates but can't be 
>> instantiated.
>
> What is the type of (42, string, dchar, false)? Is it (int, 
> string, dchar, bool) (i.e., type sequence), or is it its own 
> distinct type?

Own distinct type.

> Also, what operations can be done on a mixed tuple? Does this 
> count as instantiation?:
>
> void foo(T...)(T t) //Error?
> {
>     //...
> }

Yes, it is an error if T is not pure type sequence (it already 
is).

> You're losing me. I sort of agree as to why, but I don't the 
> idea of having two different tuples syntaces. That's part of 
> why the situation is as it is in the first place.

It has played minor role in current situation. Similar naming and 
vague meaning of TypeTuple has played major roles. Those have 
different literals because theu have _completely_ different usage 
semantics. Once those are defined and clear it is no more 
confusing than static array vs dynamic array.

>> void foo(T...)(T args)
>
> Looks like my earlier question was answered. Why is this not 
> instantiation?

It is :)

> Something else. How does tuple(1, "a") relate to ctuple(1, 
> "a"), if at all?

tuple(1, "a") == tuple(ctseq(1, "a").expand) // only relation I 
can think of

> How does ctuple(int, string) relate to ctuple(1, "a")?

Completely unrelated.

> Is there ever a case where typeof(tuple(value, value)) == 
> ctuple(value, value), or ctuple(type, type) == ctuple(value, 
> value)?

No, never.

  Great.

>> .expand should be probably defined as a simple syntax rewrite:
>>    - tuple(a, b)" to "a, b" for literals
>>    - "tupleVar" to "tupleVar[0], tupleVar[1]" for variables
>>
>> That also implies that packing / unpacking syntax, whatever it 
>> can be,
>> is completely unrelated to expansion - former can't be 
>> expressed as a simple
>> syntax rewrite, latter can't have special semantics tied to it 
>> without creating
>> even more meta-type to represent it.
>
> I don't know what you mean here.

I have changed my mind while was typing this answer :) Those may 
be more related than I have initially expected but I can't 
express it right now.

>> ----- std.typetuple.TypeTuple / std.typecons.Tuple -----
>>
>> No need to keep them other than for backwards compatibility ;)
>
> Wouldn't both break with the changes you described?

Those can be re-implemented to keep old behavior during 
deprecation period but with all the breakage I don't know if 
makes any sense/


More information about the Digitalmars-d mailing list