Fix Issue 14637 - Array operations should work on tuples by wilzbach · Pull Request #6386 · dlang/phobos

wilzbach · 2018-03-30T06:05:09Z

Other operations that have been missed?

dlang-bot · 2018-03-30T06:05:10Z

Thanks for your pull request, @wilzbach!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	4591	enhancement	Concat of std.typecons.Tuples
✓	14637	enhancement	Array operations should work on tuples

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#6386"

wilzbach · 2018-03-30T06:05:46Z

std/typecons.d

+        if (R.length > 1 && areCompatibleTuples!(typeof(this), Tuple!R, "=="))
+        {
+            return field[] == tuple(rhs).field[];
+        }


This is required for static assert(t.fieldNames == tuple("foo", "bar"));

n8sh · 2018-03-30T07:56:41Z

std/typecons.d

    {
        static assert(Tup1.Types.length == Tup2.Types.length);
-        foreach (i, _; Tup1.Types)
+        static foreach (i, _; Tup1.Types)


Since all that's happening in this is a static assert, is there a reason to prefer static foreach over foreach?

Style/clarity (see e.g. #5729)

andralex

It seems all operations that take tuples should use auto ref seeing as tuple tend to be large.

andralex · 2018-03-30T11:18:54Z

std/typecons.d

            return field[] == rhs.field[];
        }

+        bool opEquals(R...)(R rhs) const


auto ref may be helpful here

Yeah, but then DMD can no longer find a matching opEquals

Can you file a bug for auto ref opEquals?

(with the latest constraint + body changes, I can no longer reproduce this -> changed to const auto ref)

andralex · 2018-03-30T11:19:21Z

std/typecons.d

        }

+        bool opEquals(R...)(R rhs) const
+        if (R.length > 1 && areCompatibleTuples!(typeof(this), Tuple!R, "=="))


Does areCompatibleTuples also include the length check?

Yes (see above)

andralex · 2018-03-30T11:20:39Z

std/typecons.d

+        bool opEquals(R...)(R rhs) const
+        if (R.length > 1 && areCompatibleTuples!(typeof(this), Tuple!R, "=="))
+        {
+            return field[] == tuple(rhs).field[];


This is wasteful if field[] == rhs.field[] works, which would be more efficient. Why is there a need to create a temp?

Because R isn't a tuple - without it I get:

std/typecons.d(776): Error: no property field for tuple (string, string)

Got it, thanks. Well the template constraint would at best describe what the requirements on R are; currently it relies on areCompatibleTuples, which is utterly undocumented.

https://dlang.org/phobos/std_typecons.html#.Tuple.opEquals no?

andralex · 2018-03-30T11:22:18Z

std/typecons.d

+        if (op == "~")
+        {
+            static if (isTuple!T)
+                return Tuple!(AliasSeq!(T._Fields, _Fields))(t.expand, expand);


I wonder how this doesn't create an ambiguity when concatenating two tuples.

MetaLang · 2018-03-30T16:39:33Z

std/typecons.d

+        if (op == "~")
+        {
+            static if (isTuple!T)
+                return Tuple!(AliasSeq!(_Fields, T._Fields))(expand, t.expand);


I think the use of AliasSeq here is redundant, but I'm not completely sure without checking it.

MetaLang · 2018-03-30T16:40:00Z

std/typecons.d

+        if (op == "~")
+        {
+            static if (isTuple!T)
+                return Tuple!(AliasSeq!(T._Fields, _Fields))(t.expand, expand);


Same here with redundant AliasSeq.

MetaLang

I like the concept but agree with @andralex's nitpicks, so those should be addressed first.

wilzbach · 2018-04-01T10:03:14Z

std/typecons.d

            return field[] == rhs.field[];
        }

+        bool opEquals(R...)(auto ref const R rhs) const


BTW shouldn't the opEquals overloads above also use const?

MetaLang · 2018-04-03T01:54:46Z

std/typecons.d

            return field[] == rhs.field[];
        }

+        bool opEquals(R...)(const auto ref R rhs) const


I don't think const is a good idea here:

struct Test(T...) { T field; this (T t) { field = t; } bool opEquals(R...)(const auto ref R rhs) const { static foreach (i, _; T) if (field[i] != rhs[i]) return false; return true; } } struct Bad { int a; bool opEquals(Bad b) { return a == b.a; } } void main() { import std.meta; auto t = Test!(int, Bad, string)(1, Bad(1), "asdf"); //Error: mutable method Bad.opEquals is not callable using a const object assert(t == AliasSeq!(1, Bad(1), "asdf")); }

https://run.dlang.io/is/K7qFnY

Urgh. That really sucks. Well, we could duplicate the opEquals yet another time, but for now I just removed both const's and added your example to the source code, s.t. we don't regress against this.
Thanks!

Yup. It works if Bad doesn't define opEquals and lets the compiler generate it, or if it marks opEquals as const or inout. However, it has to be turtles all the way down; if Bad wraps another struct Worse which also has a custom opEquals, then Worse must also mark its opEquals with const or inout. This is impossible if Worse is a struct that you don't control, and is a pain whether you control it or not.

I think the only proper way to do this is to make sure you define an inout or const overload of opEquals iff you define a mutable one.

JackStouffer · 2018-04-03T13:20:12Z

std/typecons.d

            assert(tup1 > tup2);
        }

+        /// Allow tuple concatenation


Params, Returns

JackStouffer · 2018-04-03T13:22:29Z

std/typecons.d

            return field[] == rhs.field[];
        }

+        bool opEquals(R...)(auto ref R rhs)


not documented

wilzbach · 2018-04-04T10:47:04Z

Added a nice error message if the two concatenated tuples have non-distinct fields.

wilzbach requested review from MetaLang and PetarKirov as code owners March 30, 2018 06:05

dlang-bot added the Severity:Enhancement label Mar 30, 2018

wilzbach commented Mar 30, 2018

View reviewed changes

wilzbach force-pushed the fix-14637 branch 3 times, most recently from ecb6bcd to d8a08e4 Compare March 30, 2018 06:40

n8sh reviewed Mar 30, 2018

View reviewed changes

n8sh approved these changes Mar 30, 2018

View reviewed changes

andralex approved these changes Mar 30, 2018

View reviewed changes

MetaLang reviewed Mar 30, 2018

View reviewed changes

MetaLang approved these changes Mar 30, 2018

View reviewed changes

wilzbach force-pushed the fix-14637 branch 4 times, most recently from 23153d2 to 0274c34 Compare April 1, 2018 10:02

wilzbach commented Apr 1, 2018

View reviewed changes

wilzbach force-pushed the fix-14637 branch from 0274c34 to 1bb2bc8 Compare April 1, 2018 10:05

wilzbach added this to the 2.080.0 milestone Apr 2, 2018

n8sh added the Merge:auto-merge label Apr 3, 2018

MetaLang reviewed Apr 3, 2018

View reviewed changes

wilzbach removed the Merge:auto-merge label Apr 3, 2018

wilzbach force-pushed the fix-14637 branch from 1bb2bc8 to e7b5997 Compare April 3, 2018 06:37

JackStouffer approved these changes Apr 3, 2018

View reviewed changes

wilzbach force-pushed the fix-14637 branch from e7b5997 to 21bc635 Compare April 4, 2018 10:41

Fix Issue 4591, 14637 - Array operations should work on tuples

cddd0df

wilzbach force-pushed the fix-14637 branch from 21bc635 to cddd0df Compare April 4, 2018 10:46

JackStouffer approved these changes Apr 4, 2018

View reviewed changes

JackStouffer added the Merge:auto-merge label Apr 4, 2018

dlang-bot merged commit a62f6e3 into dlang:master Apr 4, 2018

Uh oh!

Conversation

wilzbach commented Mar 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dlang-bot commented Mar 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bugzilla references

Testing this PR locally

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andralex left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilzbach Mar 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MetaLang left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MetaLang Apr 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MetaLang Apr 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wilzbach commented Apr 4, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

wilzbach commented Mar 30, 2018 •

edited

Loading

dlang-bot commented Mar 30, 2018 •

edited

Loading

wilzbach Mar 30, 2018 •

edited

Loading

MetaLang Apr 3, 2018 •

edited

Loading

MetaLang Apr 3, 2018 •

edited

Loading