proposal: differentiate between "field" and "decl" with @field

[tgschultz]

This was discussed at the end of #1439.

In that issue the proposed @hasField builtin was split into @hasField and @hasDecl in order to differentiate between struct instance fields and struct namespaced declarations.

It is further proposed that @field either be altered in the same manner: @field/@decl or be renamed to make it clear that it refers to any "member" of a struct regardless of which it is (@member). My personal preference is the former.

related: #1836

[frmdstryr]

Agree it should be split. Also would be nice to have all three (@member, @field, @decl) and similar has variants.

Edit: Or perhaps it'd be more extensible to specify the type with the has variant? Eg, @hasMember(T, .Field, "name") then a single @member to retrieve it.

Why are these builtins at all instead of just some fn defined in std.meta / std.meta.traits? Just curious.

[tgschultz]

IIRC the reasoning is that the 'has' functions in std.meta are inefficient because they require comptime looping over TypeInfo and this case was common enough to warrant a more efficient builtin.

[Mouvedia]

I stumbled on this today while reading the documentation:

// Structs can have 0 fields.
const Empty = struct {
    pub const PI = 3.14;
};

but

assert(@field(Empty, "PI") == 3.14);

I agree this is really confusing and unexpected for newcomers.
We should have @member for both decls and fields, and have @field and @decl for fields and declarations respectively.