Proposal: rename/modify hasFn and hasField trait functions

[Airtz]

Motivation

As of now std.meta.trait.hasFn and std.meta.trait.hasField are matching on members identifiers alone.

This is not very usefull to express shared behavior.

Proposal

Match on members signatures instead.

1. Remove hasFn(comptime name: []const u8) in favor of a more generic hasDecl(comptime name: []const u8, comptime T: type)
2. Change hasField(comptime name: []const u8) to hasField(comptime name: []const u8, comptime T: type)

Usage

const trait = @import("std").meta.trait;

const isMyTrait = trait.multiTrait(.{
    trait.hasField("my_field", u8),
    trait.hasDecl("my_const", []const u8),
    trait.hasDecl("myFn", fn(bool, u8) f64),
});

Related issues

#3839 (naming coherence)
#1268 (use case)

[data-man]

#7921 ?

[Airtz]

My bad, did not see #7921. Duplicate then!

[SpexGuy]

Closing as duplicate. Feel free to reopen if there's something novel here that I missed.

[courajs]

I believe this is actually distinct from #7921 which is only suggesting an API tweak: to remove the indirection of TraitFn in favor of passing all args up front. But there's still only one type argument, the type being tested against the trait.

This proposal instead is suggesting added functionality - the ability to assert on the type of a struct field decl. There would be two type arguments involved here:

1. The type that the given decl/field should have
2. The type being tested against the trait.

I would like to be able to do this. After all, if you're expecting a next(_: *@This()) ?T but the type has a next(_: usize) usize that's obviously going to cause problems.
However, if we take this step, further things will pop up. How would you specify the type of a method with a Self argument?

So, I think this could be important functionality, but needs some further design work to figure out how to specify more complex traits. However, it could be possible that the interface complexity isn't worth it compared to more manual asserts against @typeInfo