https://issues.dlang.org/show_bug.cgi?id=8494

--- Comment #1 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
I think "bar" is supposed to return Tuple!int, not int.

--

https://issues.dlang.org/show_bug.cgi?id=8494

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
Making bar return Tuple!int results in successful compilation with git HEAD on ubuntu 16.04 64-bit. Closing as invalid.

--

https://issues.dlang.org/show_bug.cgi?id=8494

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com

--- Comment #3 from ZombineDev <petar.p.kirov@gmail.com> ---
You're misunderstanding the OP. The whole point of this enhancement request is
to make T and Tuple!T interchangeable. Changing the return type of `bar` misses
the point completely. Essentially what this OP is asking is:
1. Tuple.opAssign should return `this` (the object being modified)
2. Tuple!T should implicitly convert to T.

This comes from a higher-level goal that type constructors should be indistinguishable from built-in types - there should be nothing that user-defined can't do, that a built-in type can.

Razvan, please refrain from closing valid enhancement requests. 1-2 years ago bearophile was one of the most active community members and many of his ideas helped shape the language and the standard library. While some of his enhancement request are a bit vague and not always clear, quite often there are good ideas in there. In particular, a future proposal for built-in tuples may greatly benefit from many of his litmus tests.

--

https://issues.dlang.org/show_bug.cgi?id=8494

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to ZombineDev from comment #3)
> You're misunderstanding the OP. The whole point of this enhancement request
> is to make T and Tuple!T interchangeable. Changing the return type of `bar`
> misses the point completely. Essentially what this OP is asking is:
> 1. Tuple.opAssign should return `this` (the object being modified)
> 2. Tuple!T should implicitly convert to T.
> 
> This comes from a higher-level goal that type constructors should be
> indistinguishable from built-in types - there should be nothing that
> user-defined can't do, that a built-in type can.
> 
> Razvan, please refrain from closing valid enhancement requests. 1-2 years
> ago bearophile was one of the most active community members and many of his
> ideas helped shape the language and the standard library. While some of his
> enhancement request are a bit vague and not always clear, quite often there
> are good ideas in there. In particular, a future proposal for built-in
> tuples may greatly benefit from many of his litmus tests.

Sorry for my misunderstanding, but closing a bug report which seems invalid is the most efficient way to bring it to the attention of everyone.

--

https://issues.dlang.org/show_bug.cgi?id=8494

--- Comment #5 from ZombineDev <petar.p.kirov@gmail.com> ---
> Sorry for my misunderstanding, but closing a bug report which seems invalid is the most efficient way to bring it to the attention of everyone.

No problem, the only issue is that people on the CC list are guaranteed to be
notified that the bug is closed. I saw this one only by chance.
On the other hand, we do need to triage bugs, so we need an efficient solution
for this. How about we setting up a bug-triage channel on Slack?

--

https://issues.dlang.org/show_bug.cgi?id=8494

--- Comment #6 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to ZombineDev from comment #5)
> > Sorry for my misunderstanding, but closing a bug report which seems invalid is the most efficient way to bring it to the attention of everyone.
> 
> No problem, the only issue is that people on the CC list are guaranteed to
> be notified that the bug is closed. I saw this one only by chance.
> On the other hand, we do need to triage bugs, so we need an efficient
> solution for this. How about we setting up a bug-triage channel on Slack?

That is a great idea. Unfortunately, I am not very well versed with Slack, so do you mind creating the channel?

--

https://issues.dlang.org/show_bug.cgi?id=8494

--- Comment #7 from ZombineDev <petar.p.kirov@gmail.com> ---
(In reply to RazvanN from comment #6)
> 
> That is a great idea. Unfortunately, I am not very well versed with Slack, so do you mind creating the channel?

Done, you should have gotten an invitation. If you log in on Slack, you should see the channel somewhere on your left.

--

https://issues.dlang.org/show_bug.cgi?id=8494

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras@gmail.com

--- Comment #8 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
As has been pointed out, part of this bug is a two-line fix in typecons.d to have opAssign return ref Tuple. (PR: https://github.com/dlang/phobos/pull/5713)

The other part is bigger - we're looking at either multiple alias this or implicitly casting AliasSeq!(3) to int. I'd argue the latter is probably the best solution here. At any rate, that's a DMD fix, not Phobos.

--

https://issues.dlang.org/show_bug.cgi?id=8494

--- Comment #9 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
Factored out the easy fix to a separate issue (issue 17803), to retain
discussion of core issue here.

--

https://issues.dlang.org/show_bug.cgi?id=8494

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--