[Issue 8494] Return value for Tuple.opAssign

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

--- Comment #9 from Simen Kjaeraas  ---
Factored out the easy fix to a separate issue (issue 17803), to retain
discussion of core issue here.

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #8 from Simen Kjaeraas  ---
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.

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

--- Comment #7 from ZombineDev  ---
(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.

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

--- Comment #6 from RazvanN  ---
(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?

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

--- Comment #5 from ZombineDev  ---
> 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?

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

--- Comment #4 from RazvanN  ---
(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.

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #3 from ZombineDev  ---
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.

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

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

--

[Issue 8494] Return value for Tuple.opAssign

[via Digitalmars-d-bugs]

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

--- Comment #1 from Vladimir Panteleev  ---
I think "bar" is supposed to return Tuple!int, not int.

--