Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 23, 2020 More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
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)) . |
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | 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.
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 |
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 != ?
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dennis | 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
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dennis | 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
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
August 23, 2020 Re: More operators inside `is(...)` expressions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dennis | 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
|
Copyright © 1999-2021 by the D Language Foundation