Tuple range interface

[JakobOvrum]

Adds a range interface for tuples with homogeneous types. The introduced range interface presents the fields by reference, so it's very different from only(myTuple.expand), as the examples show.

The whitespace fixes are in a separate commit, so the diff for the second commit is probably easier to look at than the total diff.

Could the new return attribute help with making this a memory safe interface?

---

Do tuples with internal padding exist? Or rather, do template argument lists with padding exist? I wasn't able to produce any with DMD32/Windows/OMF; I do have the code that handles it properly so it's readily available if padding is possible. Right now this patch includes a static assert checking that no tuple with padding is ever instantiated.

---

Apparently, documented unittests inside a documented static-if like this confuses DDoc quite severely, so the DDoc description is duplicated three times in the output. I'll see if the bug tracker has anything on this.

[MetaLang]

Do you think there's any value in also supporting Tuples whose types can all implicitly convert to some supertype?

[JakobOvrum]

I thought about this, but ultimately, I think it's better without. The biggest issue is that the element type wouldn't be an lvalue like it is with the current implementation.

[MetaLang]

This is an interesting PR, but it suffers somewhat from the fact that the following code works:

import std.array: array;
import std.typecons: Tuple;

void main()
{
    Tuple!(int, int, int) intTup;
    int[] tupArr1 = intTup.array;
    int[] tupArr2 = [intTup.expand];
    //Curiously *doesn't* work
    //int[] tupArr3 = intTup.to!(int[]);
}

And there is also as an option, as you said, only(intTup.expand). All of these options have the benefit of being @safe as well. The only real advantage of Tuple.range is that it doesn't allocate, but safety is sacrificed to achieve this, and thus it won't be usable in large swathes of code.

[JakobOvrum]

The only real advantage of Tuple.range is that it doesn't allocate

No. The real advantage is that the range it returns refers to the original elements by reference, allowing code like the examples.

[monarchdodra]

Otherwise known as T.length <= 1 ;)

[JakobOvrum]

I think this is more explicit, i.e. "match the nullary and unary cases".

[andralex]

That's more likely to raise a brow with most maintainers than the simpler condition, so please change and let's merge this. I approve the PR and will archive this.

[JakobOvrum]

areAllSame now uses allSatisfy for better recursion performance. We should have a template so that we could do Types.length && allSatisfy!(isExactly!(Types[0]), Types) right there in the template constraint for range, but that's beyond the scope of this PR, hence why this patch has areAllSame to begin with.

[andralex]

This is fine. In the future we may expand functionality to the empty tuple and tuples that contain qualified types with different qualifiers etc.

[JakobOvrum]

Fixed the awkward condition and rebased.

[JakobOvrum]

Amended it to handle tuples containing types of varying mutability. For nullary only() we made the element type int - should I go ahead and do the same for the empty tuple?

[dlang-bot]

Fix	Bugzilla	Description
✓	5489	std.typecons tuples dynamically iterable
✓	9871	std.typecons.asArray

[MetaLang]

If you put the unittest inside the struct, there will be a new unittest instantiated each time Tuple is instantiated. Jonathan Davis pointed this out in the newsgroup and I think it's something we should avoid.

[JakobOvrum]

Yeah, but it should be done for the whole type. I pointed out the same in #3594.

[wilzbach]

Ndslice does this a lot, too.
AFAIK this works as long as the are enough outside tests covering all types.
See #4050

[JakobOvrum]

It's a performance issue: code is generated and executed an unnecessary amount of times. I haven't heard of any measurements indicating that Tuple in particular is a problem but it's good to avoid in principle.

[wilzbach]

how about adding version (unittest){}?

[wilzbach]

I have suffered from the bad interoperability between tuples and arrays a lot since I started with D and I would like to see this coming too :)

If I understood this PR, this we can do this in both ways?

Tuple!(int, int) tup = tuple(1, 2);
auto arr1 = tup.range; 
assert(tup == arr1);

// and back again
auto arr2 = [3, 4]
tuple.range = arr2; 
assert(tup == arr2);

Would be pretty useful!

[JakobOvrum]

Neither of the two operations you posted would work with this. There is a distinction between arrays and ranges, and this PR adds a range interface, not an array interface, to tuples.

Here's how you do those operations in range style:

Tuple!(int, int) tup = tuple(1, 2);
int[] arr1 = tup.range.array; // Assuming you meant making a copy, as otherwise you'd just compare the slice with itself
assert(tup.range == arr1);

// and back again
int[] arr2 = [3, 4];
arr2.copy(tuple.range);
assert(tup.range == arr2);

[wilzbach]

Neither of the two operations you posted would work with this. There is a distinction between arrays and ranges, and this PR adds a range interface, not an array interface, to tuples.

What do you think about adding this example as another visible unittest in the documentation?

[wilzbach]

@JakobOvrum now autotester fails ...

[DmitryOlshansky]

@JakobOvrum now autotester fails ...

OMG looks like compiler internal error, all more valuable to reduce.

[wilzbach]

OMG looks like compiler internal error, all more valuable to reduce.

Then let's bug it? Do you get from the error message what exactly fails? Is someone here using FreeBSD?

[JackStouffer]

No activity from the author in nine months. Closing.