Hi,

I faced a little trouble and can not decide if it is a my
mistake, a bug in std library or in compiler…

Look:

$ cat enum_of_structs.d
struct T {
	int v;
	int opCmp( T rhs ) { return v == rhs.v ? 0 : ( v < rhs.v ? -1 :
+1 ); };
	
};
enum E : T {
	A = T( 1 ),
	B = T( 2 ),
};
$ dmd -c -w enum_of_structs.d

Output is empty — there is no warnings and/or errors.

In the next example I decide to use std.typecons module instead
of declaring struct manually:

$ cat enum_of_tuples.d
import std.typecons;
alias Tuple!( int, "v" ) T;
enum E : T {
	A = T( 1 ),
	B = T( 2 ),
};
$ dmd -c -w enum_of_tuples.d
enum_of_tuples.d(5): Error: template
std.typecons.Tuple!(int,"v").Tuple.opCmp does not match any
function template declaration
/usr/include/d/dmd/phobos/std/typecons.d(423): Error: template
std.typecons.Tuple!(int,"v").Tuple.opCmp(R) if (isTuple!(R))
cannot deduce template function from argument types !()(E)
enum_of_tuples.d(5): Error: template
std.typecons.Tuple!(int,"v").Tuple.opCmp does not match any
function template declaration
/usr/include/d/dmd/phobos/std/typecons.d(423): Error: template
std.typecons.Tuple!(int,"v").Tuple.opCmp(R) if (isTuple!(R))
cannot deduce template function from argument types !()(E)

Oops. What the problem?

BTW, I use DMD64 D Compiler v2.060 on Fedora 17. ldc2 compiler (LLVM D Compiler LDC trunk, based on DMD v2.059 and LLVM 3.0) produces similar results:

$ ldc2 -c -w enum_of_tuples.d
enum_of_tuples.d(5): Error: template std.typecons.Tuple!(int,"v").Tuple.opCmp does not match any function template declaration
/usr/include/d/std/typecons.d(422): Error: template std.typecons.Tuple!(int,"v").Tuple.opCmp(R) if (isTuple!(R)) cannot deduce template function from argument types !()(E)
enum_of_tuples.d(5): Error: template std.typecons.Tuple!(int,"v").Tuple.opCmp does not match any function template declaration
/usr/include/d/std/typecons.d(422): Error: template std.typecons.Tuple!(int,"v").Tuple.opCmp(R) if (isTuple!(R)) cannot deduce template function from argument types !()(E)

Van de Bugger:

> Oops. What the problem?

I seems one or more bugs. D named enums are adapted from the C language, they were first of all meant to contain simple values like ints or chars. The more complex things you keep trying to put in them, the more bugs you will find :-) People in D.learn keep trying to put complex things in them, but maybe Walter has not even tested them with more complex types, like class instances.

Bye,
bearophile

On Wednesday, September 26, 2012 23:24:08 bearophile wrote:
> Van de Bugger:
> > Oops. What the problem?
> 
> I seems one or more bugs. D named enums are adapted from the C language, they were first of all meant to contain simple values like ints or chars. The more complex things you keep trying to put in them, the more bugs you will find :-) People in D.learn keep trying to put complex things in them, but maybe Walter has not even tested them with more complex types, like class instances.

Classes will not work for the same reason that you can never use a class object as an enum with manifest constants. It's a long-standing bug that structs don't work as enums (other than manifest constants) even though they're supposed to according to TDPL:

http://d.puremagic.com/issues/show_bug.cgi?id=4423

>From the sounds of it though, if Tuple fixes its signatures for opCmp, it can
be made to work. Regardless, it should be reported that tuples don't work as enums other than manifest constants.

- Jonathan M Davis

On 2012-09-27, 00:02, Jonathan M Davis wrote:

> Classes will not work for the same reason that you can never use a class
> object as an enum with manifest constants.

Has a decision been made as to whether or not this will be possible in the
future?

-- 
Simen

On Friday, September 28, 2012 03:56:39 Simen Kjaeraas wrote:
> On 2012-09-27, 00:02, Jonathan M Davis wrote:
> > Classes will not work for the same reason that you can never use a class object as an enum with manifest constants.
> 
> Has a decision been made as to whether or not this will be possible in the future?

No such promise has been made. It's a huge implementation problem to do it. It _may_ be done at some point, but the difficulties involve make it so that it's not at all certain that it will ever happen. Anything involving saving pointers from compile time to reuse at runtime is incredibly problematic (if nothing else, because none of the addresses that they have at compile time will be valid at runtime). Dynamic arrays are the only case where anything like that occurs, and it may very well be that that's the way that it'll always be. We'll just have to wait and see. Certainly, it won't happen any time soon.

- Jonathan M Davis