Return value for Tuple.opAssign

[dlangBugzillaToGithub]

bearophile_hugs reported this on 2012-08-02T12:11:00Z

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

CC List

• petar.p.kirov
• razvan.nitu1305
• simen.kjaras

Description

I'd like this operation to be supported:


import std.typecons;
int foo() {
    int[2] a;
    return a[1] = 5; // ok
}
int bar() {
    Tuple!(int)[2] a;
    return a[1] = tuple(5); // error
}
void main() {}


DMD 2.060beta4 gives:

temp.d(8): Error: cannot implicitly convert expression (a[1u].opAssign(tuple(5))) of type void to int

[dlangBugzillaToGithub]

dlang-bugzilla (@CyberShadow) commented on 2017-07-01T18:52:46Z

I think "bar" is supposed to return Tuple!int, not int.

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 2017-08-28T09:03:14Z

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

[dlangBugzillaToGithub]

petar.p.kirov commented on 2017-08-29T09:48:45Z

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.

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 2017-08-30T07:59:37Z

(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.

[dlangBugzillaToGithub]

petar.p.kirov commented on 2017-08-30T08:09:49Z

> 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?

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 2017-08-30T09:07:11Z

(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?

[dlangBugzillaToGithub]

petar.p.kirov commented on 2017-08-30T09:11:51Z

(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.

[dlangBugzillaToGithub]

simen.kjaras commented on 2017-08-30T11:16:53Z

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.

[dlangBugzillaToGithub]

simen.kjaras commented on 2017-09-04T06:01:03Z

Factored out the easy fix to a separate issue (issue 17803), to retain discussion of core issue here.