Why aren't more operators allowed inside `is(...)`-expressions?

For instance

    if (!is(CommonType!(typeof(min), typeof(max)) == void))

could be written as

    if (is(CommonType!(typeof(min), typeof(max)) != void))

.

On Sunday, 23 August 2020 at 21:08:30 UTC, Per Nordlöw wrote:
> Why aren't more operators allowed inside `is(...)`-expressions?
>
> For instance
>
>     if (!is(CommonType!(typeof(min), typeof(max)) == void))
>
> could be written as
>
>     if (is(CommonType!(typeof(min), typeof(max)) != void))
>
> .

Because you don't want to make them even more complicated than they are already.

On 8/23/20 5:12 PM, Stefan Koch wrote:
> On Sunday, 23 August 2020 at 21:08:30 UTC, Per Nordlöw wrote:
>> Why aren't more operators allowed inside `is(...)`-expressions?
>>
>> For instance
>>
>>     if (!is(CommonType!(typeof(min), typeof(max)) == void))
>>
>> could be written as
>>
>>     if (is(CommonType!(typeof(min), typeof(max)) != void))

I agree. There's a reason we have != and don't require people to write !(x == y)

> 
> Because you don't want to make them even more complicated than they are already.

This one though is really annoying. I've bristled at that a few times when I had to write it.

What is the cost here? Just use the same AST node for the is expression, and wrap it in a `not` AST node.

-Steve

On Sunday, 23 August 2020 at 21:20:21 UTC, Steven Schveighoffer wrote:
> On 8/23/20 5:12 PM, Stefan Koch wrote:
>> On Sunday, 23 August 2020 at 21:08:30 UTC, Per Nordlöw wrote:
>>> Why aren't more operators allowed inside `is(...)`-expressions?
>>>
>>> For instance
>>>
>>>     if (!is(CommonType!(typeof(min), typeof(max)) == void))
>>>
>>> could be written as
>>>
>>>     if (is(CommonType!(typeof(min), typeof(max)) != void))
>
> I agree. There's a reason we have != and don't require people to write !(x == y)
>
>> 
>> Because you don't want to make them even more complicated than they are already.
>
> This one though is really annoying. I've bristled at that a few times when I had to write it.
>
> What is the cost here? Just use the same AST node for the is expression, and wrap it in a `not` AST node.
>
> -Steve

True, though how is pattern matching going to work if you allow != ?

On Sunday, 23 August 2020 at 21:20:21 UTC, Steven Schveighoffer wrote:
> What is the cost here? Just use the same AST node for the is expression, and wrap it in a `not` AST node.

What would `is(int != T, T)` mean? To me it sounds like T should be bound to an arbitrary type that's not int, but when you lower it to `!is(int == T, T)` it returns false.

On 8/23/20 5:52 PM, Dennis wrote:
> On Sunday, 23 August 2020 at 21:20:21 UTC, Steven Schveighoffer wrote:
>> What is the cost here? Just use the same AST node for the is expression, and wrap it in a `not` AST node.
> 
> What would `is(int != T, T)` mean? To me it sounds like T should be bound to an arbitrary type that's not int, but when you lower it to `!is(int == T, T)` it returns false.

I don't get this question at all.

What does that mean anyway? According to the grammar, the `, T` part is supposed to be template parameters.

And what is wrong with:

static if (is(int != T))
{
   // use T
}

-Steve

On 8/23/20 5:52 PM, Dennis wrote:
> On Sunday, 23 August 2020 at 21:20:21 UTC, Steven Schveighoffer wrote:
>> What is the cost here? Just use the same AST node for the is expression, and wrap it in a `not` AST node.
> 
> What would `is(int != T, T)` mean? To me it sounds like T should be bound to an arbitrary type that's not int, but when you lower it to `!is(int == T, T)` it returns false.

BTW, what I would propose is that the following case be added as an is Expression:

is(Type != TypeSpecialization)

As syntax sugar for:

!is(Type == TypeSpecialization)

And no other forms using != are valid.

-Steve

On Sunday, 23 August 2020 at 22:11:41 UTC, Steven Schveighoffer wrote:
> static if (is(int != T))
> {
>    // use T
> }

Furthermore, what's wrong with allowing

static if (int is T)
{
   // use T
}

static if (int !is T)
{
   // use T
}

?

Less syntax for developer to remember.

On Sunday, 23 August 2020 at 22:17:49 UTC, Steven Schveighoffer wrote:
> BTW, what I would propose is that the following case be added as an is Expression:
>
> is(Type != TypeSpecialization)
>
> As syntax sugar for:
>
> !is(Type == TypeSpecialization)
>
> And no other forms using != are valid.

In that case the unclear `is(int != T, T)` case does not apply anymore. But that would only expand the (already confusing) list of is-expression forms with another special case.

On 8/23/20 6:25 PM, Dennis wrote:
> On Sunday, 23 August 2020 at 22:17:49 UTC, Steven Schveighoffer wrote:
>> BTW, what I would propose is that the following case be added as an is Expression:
>>
>> is(Type != TypeSpecialization)
>>
>> As syntax sugar for:
>>
>> !is(Type == TypeSpecialization)
>>
>> And no other forms using != are valid.
> 
> In that case the unclear `is(int != T, T)` case does not apply anymore. But that would only expand the (already confusing) list of is-expression forms with another special case.

I think the not-confusing not-special-case is expression boat didn't sail. It sank in the harbor.

We have already sailed on the confusing is boat.

At least it should be less annoying while we are on the journey.

Is there a reason you prefer writing !is(T == U) to is(T != U)? Or are you looking to define more things?

-Steve