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

John Colvin <john.loughran.colvin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |regression

--- Comment #1 from John Colvin <john.loughran.colvin@gmail.com> ---
This is a regression introduced in 2.065, before which .length and .ptr were found. AFAICT .capacity never worked

--

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

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
The problem here is that (int[]).length is not a valid D construction:

static assert(__traits(compiles, (int[]).length));

will fail, therefore traits(hasMember) returns false.

length, ptr and capacity were thought to work solely on expressions, not on types (it doesn't make sense to get the pointer of a type) so I'm a bit confused of what the compiler should do here.

sizeof and alignof work because there are type properties.

--

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

--- Comment #3 from RazvanN <razvan.nitu1305@gmail.com> ---
Note that if a variable is declared:

int[] a;

traits(hasMember) on a works properly.

--

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

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
As for capacity, it is not listed on the list of properties for arrays and it is implemented as a druntime function. I guess this bug report opens the philosophical question of what hasMember actually means. For example, sizeof is not actually a member of any type, it is a property that may be queried; that property may be implemented as a function directly in the compiler or it may be a function in druntime or it may be an actual member of the int class; this all depends on how it was actually implemented, which is not something that the user cares.

In my opinion, hasMember should only work on aggregates, because there we are talking about actual scope declarations that have members. builtin types should all return false on hasMember queries because builtin types don't have any members, rather they have properties. If you want to see what properties a type has you can simply use traits(compiles).

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
I agree that hasMember should only work on aggregates. UFCS functions that syntactically look like members are still not members.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
> traits(hasMember) on a works properly.

Meaning:

int[] array;
pragma(msg, __traits(hasMember, array, "length"));   // true
pragma(msg, __traits(hasMember, array, "ptr"));      // true
pragma(msg, __traits(hasMember, array, "capacity")); // true
pragma(msg, __traits(hasMember, array, "sizeof"));   // true
pragma(msg, __traits(hasMember, array, "alignof"));  // true

Gaahhh. It's probably far too late to change this behavior now.

Marking as WONTFIX.

--