• Russel Winder (26/26) May 20 2020 So I have an enum:
• Steven Schveighoffer (10/35) May 20 2020 The issue is that it's not EXACTLY a Tuple, because it's a derived type....
• Simen =?UTF-8?B?S2rDpnLDpXM=?= (5/6) May 20 2020 https://issues.dlang.org/show_bug.cgi?id=20850

Russel Winder <russel winder.org.uk> writes:

So I have an enum:

   enum RC5Command: Tuple!(ubyte, ubyte) {
       Standby =3D tuple(to!ubyte(0x10), to!ubyte(0x0c)),
       =E2=80=A6

I can do:

   RC5Command rc5command =3D RC5Command.CD;

However, if I do:

   rc5command =3D RC5Command.BD;

I get:

source/functionality.d(80,16): Error: template std.typecons.Tuple!(ubyte, u=
byte).Tuple.opAssign cannot deduce function from argument types !()(RC5Comm=
and), candidates are:
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/typecons.d(900,19):        opAs=
sign(R)(auto ref R rhs)
  with R =3D RC5Command
  must satisfy the following constraint:
       areCompatibleTuples!(typeof(this), R, "=3D")

which is totally unreasonable. And yet D insists. I guess there is an
explanation, but mostly this seems like a bug.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

Steven Schveighoffer <schveiguy gmail.com> writes:

On 5/20/20 8:17 AM, Russel Winder wrote:
 So I have an enum:
 
     enum RC5Command: Tuple!(ubyte, ubyte) {
         Standby = tuple(to!ubyte(0x10), to!ubyte(0x0c)),
         …
 
 I can do:
 
     RC5Command rc5command = RC5Command.CD;
 
 However, if I do:
 
     rc5command = RC5Command.BD;
 
 I get:
 
 source/functionality.d(80,16): Error: template std.typecons.Tuple!(ubyte,
ubyte).Tuple.opAssign cannot deduce function from argument types
!()(RC5Command), candidates are:
 /usr/lib/ldc/x86_64-linux-gnu/include/d/std/typecons.d(900,19):       
opAssign(R)(auto ref R rhs)
    with R = RC5Command
    must satisfy the following constraint:
         areCompatibleTuples!(typeof(this), R, "=")
 
 which is totally unreasonable. And yet D insists. I guess there is an
 explanation, but mostly this seems like a bug.
 

The issue is that it's not EXACTLY a Tuple, because it's a derived type. 
So it fails isTuple (In fact, I think the compiler just isn't smart 
enough to detect that it can be implicitly converted to a Tuple).

But that defeats a lot of wrapping mechanisms, which I think is unnecessary.

I think there should probably be an overload:

opAssign(Tuple t) {expand = t.expand;}

that trumps the template one. That should I think take care of it.

Please file an issue.

-Steve

Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:

On Wednesday, 20 May 2020 at 13:51:05 UTC, Steven Schveighoffer 
wrote:
 Please file an issue.

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

--
   Simen