More operators inside `is(...)` expressions

[Steven Schveighoffer]

On 8/24/20 1:17 PM, Timon Gehr wrote:
> On 24.08.20 13:49, Steven Schveighoffer wrote:
>>>
>>
>> Yes. If you write !is(T == void), then you are already not checking 
>> whether T is defined. This is no different.
>>
> 
> So far the pattern is `is(S op T)`. It checks whether S is a valid type 
> and then checks `S op T`.

But op is only '==' or ':', which are in sync with the requirements 
without needing the first part (if S is invalid, then obviously it can't 
equal T, or be convertible to T). We have room to add other ops that 
might have a slightly different behavior.

That being said, if it could be added so is(S != T) is false if S is 
invalid I wouldn't object.

> 
>> This literally is just a nicer way to write it, where the operation is 
>> closer to the parameters, instead of partly outside the expression.
> 
> (I think the implications any of this has for the compiler 
> implementation or the user experience has been greatly exaggerated.)

The problem is usually something like:
static if (!is(Some!(Long!(Chain, Of, Template, Parameter, Data) == int));

At a glance, seeing that initial '!' among the various instantiation 
'!', and associating it with the check at the very end '==', is 
difficult for code review.

It's ok, it's just not ideal in terms of focusing the reader on the 
operation at hand.

This isn't a must-have, it's just something that has annoyed me multiple 
times (where I am reading code, trying to figure out why it's doing what 
it's doing, and then realize I missed the '!' at the front).

Really, all the arguments for having '!=' for binary operations vs doing 
!(someExpr == otherExp) apply here. I also really don't find the "it 
will complicate the compiler" arguments convincing.

-Steve