Bug 2873 – typeof() for member functions evaluated incorrectly

// Copied/pasted from std.range, added pragma. template hasLength(R) { pragma(msg, typeof(R.init.length).stringof); // (uint())() enum bool hasLength = is(typeof(R.init.length) : ulong); } struct Foo { uint length() { return 0; } } const Foo foo; static assert(hasLength!(Foo)); // Fails. This is pretty serious because it makes important functionality in the new Phobos unusable. However, an easy workaround to fix Phobos until the underlying DMD bug gets fixed is: enum bool hasLength = is(typeof(R.init.length) : ulong) || is(typeof(R.init.length()) : ulong); Also, what the heck is a (uint())() ?

*** Issue 3508 has been marked as a duplicate of this issue. ***

Since adding @property, this behavior isn't a bug. length method should be a property. Please use @property for length method.

Masahiro Nakagawa, I am not sure I understand this bug report and your answer well. But if I understand them, then then if you are right, and length method should be a property, then the compiler has to give a compile time error if you try to define a non-property length method, otherwise it's too much easy to write a bug.

(In reply to comment #3) > Masahiro Nakagawa, I am not sure I understand this bug report and your answer > well. Old D's property is a syntactic sugar(member function automatically becomes property), so typeof() should have evaluated .length and .length() correctly. But now, D has @property. User can choose property or non-property. > But if I understand them, then then if you are right, and length method > should be a property, then the compiler has to give a compile time error if you > try to define a non-property length method, otherwise it's too much easy to > write a bug. I agree because I can't image non-property length. I think D's compiler should print warning message if user tries to define non-property length.