> import std.typecons: Tuple, tuple;
> import std.algorithm: reduce;
>
> struct Foo { int x; }
>
> auto foo(in Tuple!(Foo[]) arg, int) {
>     return tuple(arg[0]);
> }
>
> void main() {
>     int[] data;
>     Foo[] empty;
>     auto seed = tuple(empty);
>     reduce!foo(seed, data);
> }

I have found a solution:

import std.typecons: Tuple, tuple;
import std.algorithm: reduce;

auto foo(in Tuple!(const(int)[]) arg, int) {
    return tuple(arg[0]);
}

void main() {
    int[] empty;
    Tuple!(const(int)[]) seed;
    reduce!foo(seed, [1]);
}


Bye,
bearophile

On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
> They are not the same type:
>
>
> void main() {
>     import std.typecons: Tuple;
>     alias T1 = const Tuple!(int, int);
>     alias T2 = Tuple!(const int, const int);
>     static assert(is(T1 == T2)); // Fails.
> }
>
>
> This type difference causes some troubles when you use tuples.
>
> Bye,
> bearophile

I think it's a bad idea to make these equal for this reason: if T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However:

alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
assert(is(T1 == T2));

alias UnT1 = Unqual!T1; // Tuple!(int, int)
alias UnT2 = Unqual!T2; // Tuple!(const int, const int)
assert(is(UnT1 == UnT2));

Meta:

> I think it's a bad idea to make these equal for this reason: if T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However:
>
> alias T1 = const Tuple!(int, int);
> alias T2 = Tuple!(const int, const int);
> assert(is(T1 == T2));
>
> alias UnT1 = Unqual!T1; // Tuple!(int, int)
> alias UnT2 = Unqual!T2; // Tuple!(const int, const int)
> assert(is(UnT1 == UnT2));

If we introduce structural typing for tuples (to make T1 and T2 the same type), then Unqual!T2 is Tuple!(int, int). It's like for a const(const(int)[2]).

Bye,
bearophile

On Friday, 25 April 2014 at 13:18:13 UTC, bearophile wrote:
> Dicebot:
>
>> It would be weird exception of general type system rules with no practical justification I can readily imagine.
>
> I partially disagree. It could be useful to have structural typing (http://en.wikipedia.org/wiki/Structural_type_system ) only on tuples (and not on structs), because the formal definition of tuple goes well with structural typing. This also implies the type equivalence of const tuple with a tuple of const fields.
>
> Bye,
> bearophile

Again, you refer to some sort of formal definition of tuple which is not applicable to D. We don't have real tuples in D. There are structures that emulate some of tuple properties and there is a built-in feature that is called tuple but is not one in practice.

For your objections to make sense tuple would need to be inroduced as completely new first class type system entity. As this will never happen, discussion of imaginary "proper" tuple traits is also unapplicable.

Dicebot:

> For your objections to make sense tuple would need to be inroduced as completely new first class type system entity. As this will never happen,

I think first class tuples will happen in D, because the current tuple situation is quite bad.

But this thread is not about built-in tuples, here we are discussing about possible improvements to the Phobos implementation of tuples.

A possible solution is an optional "@structural" attribute for structs that gives structural typing to one struct (that will be used as underlying implementation for library-defined tuples.

Bye,
bearophile