More operators inside `is(...)` expressions
schveiguy at gmail.com
Mon Aug 24 17:36:46 UTC 2020
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.
More information about the Digitalmars-d