Proposal (Question?): Allow decl literals in == and != peer-type resolution (PTR)

[rohlem]

Now that I've frequently used decl literals, I've come across the irregularity that == and != expressions don't seem to support them:

comptime {
    const E = enum {
        little,
        big,
        pub const native = .little; //same behavior with @This().little, if you're wondering
    };
    const foo: E = .native; //works
    _ = if (foo == @as(E, .native)) {}; //works
    _ = if (foo != @as(E, .native)) {}; //works
    _ = if (foo == .small) {}; //works (added in later EDIT)
    _ = if (foo != .small) {}; //works (added in later EDIT)
    //_ = if (foo == .native) {}; //error: no field named 'native' in enum '.zig.comptime__enum_83'
    //_ = if (foo != .native) {}; //error: no field named 'native' in enum '.zig.comptime__enum_83'
    _ = if (@TypeOf(foo, .native) != E) unreachable; //however, this works too
}

The intent behind the usage seems perfectly clear to me, therefore I'm surprised this isn't be supported.
Since general PTR via multi-argument @TypeOf accepts them, the only explanation I have is that there is special code for == and !=
(that might be for providing the enum literal name as part of the compile error message if I had to guess)
that simply wasn't updated when decl literals were introduced.

I didn't see any special mention of == and != in the "accepted" variant of the proposal, nor in the PR implementing it.
If this usage was simply overlooked, then adding support should be fairly uncontroversial. (IMO it removes a special case and simplifies the language.)

[alexrp]

cc @mlugg

[mlugg]

Decl literals don't have baked-in support for specific syntax forms; rather, they are based on result types. As such, this could only work if == were made to provide a result type to its second operand. If you want this to work, please open a proposal to provide this result type, detailing what the type is / how it is computed from the LHS.

[rohlem]

@mlugg Noted, thanks for the quick answer!
Honestly, if it's up to me to open a proposal it would just be the original post rephrased:

== and != should provide a result type to their operands based on the following rules:

1. If one operand is of an enum type and the other is of an enum literal type, the enum operand's type is used as result type for the enum literal typed operand.
   (There's already some point where such handling exists, as enum field literals work - that handling could either be extended to decl literals, or removed assuming that the result type mechanism will do the same thing.)
2. [All the unchanged rules from status-quo.]
   I know that comparison of comptime_int with other integers, and of optional types with null work for example,
   but I don't see the point (as in, for me personally) to write down all the details of status-quo I'm already happy with.

Seeing as you want a proposal, I assume there is something wrong with the approach of improving this scenario in isolation.

[mlugg]

If one operand is of an enum type and the other is of an enum literal type, the enum operand's type is used as result type of the enum literal typed operand.

The result type for the RHS of == would have to be based entirely on the LHS; we need to know the result type to apply to the RHS before evaluating it. Perhaps it would be okay to simplify the rule to the following:

• If the LHS of == or != is an enum type, the RHS receives that same enum type as a result type.