Why not allow equality operators to operate on types?

is(==) expressions tend to create bracket noise and treat the two
arguments non-uniformly.

This would suggest a little parser update, so that eg. 'int', '(int*)'
and 'int[]' are accepted as valid expressions. (this also potentially
improves compiler error messages.)

void foo(T)(T arg){
    static if(T==int){
        ...
    }else{
        ...
    }

    static if(T!=double) ...
}

As far as I can see, this would be fully backwards-compatible.
(modulo compile-time introspection.)

On 15.06.2012 16:11, Timon Gehr wrote:
> Why not allow equality operators to operate on types?
>
> is(==) expressions tend to create bracket noise and treat the two
> arguments non-uniformly.
>
> This would suggest a little parser update, so that eg. 'int', '(int*)'
> and 'int[]' are accepted as valid expressions. (this also potentially
> improves compiler error messages.)
>
> void foo(T)(T arg){
> static if(T==int){
> ...
> }else{
> ...
> }
>

Now one day some n00b uses run-time if-chains to create type-switch (that doesn't work because it would CT-defined):
...
if( typeof(a) == Foo)
...
else if(typeof(a) == Bar)
...

Though "code is unreachable" warning might help with it.
> static if(T!=double) ...
> }
>
> As far as I can see, this would be fully backwards-compatible.
> (modulo compile-time introspection.)


-- 
Dmitry Olshansky

Timon Gehr:

> Why not allow equality operators to operate on types?

That's nice, of course. But is it possible?

Bye,
bearophile

On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:
> On 15.06.2012 16:11, Timon Gehr wrote:
>> Why not allow equality operators to operate on types?
>>
>> is(==) expressions tend to create bracket noise and treat the two
>> arguments non-uniformly.
>>
>> This would suggest a little parser update, so that eg. 'int', '(int*)'
>> and 'int[]' are accepted as valid expressions. (this also potentially
>> improves compiler error messages.)
>>
>> void foo(T)(T arg){
>> static if(T==int){
>> ...
>> }else{
>> ...
>> }
>>
>
> Now one day some n00b uses run-time if-chains to create type-switch
> (that doesn't work because it would CT-defined):
> ...
> if( typeof(a) == Foo)
> ...
> else if(typeof(a) == Bar)
> ...
>

...
if(is(typeof(a) == Foo))
...
else if(is(typeof(a) == Bar)(
...

> Though "code is unreachable" warning might help with it.

Or any of the other compile time errors that is generated in the
unreachable code because it cannot compile with the given parameters.

On 06/15/2012 02:19 PM, bearophile wrote:
> Timon Gehr:
>
>> Why not allow equality operators to operate on types?
>
> That's nice, of course. But is it possible?
>

Yes, certainly.

On 15.06.2012 16:56, Timon Gehr wrote:
> On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:
>> On 15.06.2012 16:11, Timon Gehr wrote:
>>> Why not allow equality operators to operate on types?
>>>
>>> is(==) expressions tend to create bracket noise and treat the two
>>> arguments non-uniformly.
>>>
>>> This would suggest a little parser update, so that eg. 'int', '(int*)'
>>> and 'int[]' are accepted as valid expressions. (this also potentially
>>> improves compiler error messages.)
>>>
>>> void foo(T)(T arg){
>>> static if(T==int){
>>> ...
>>> }else{
>>> ...
>>> }
>>>
>>
>> Now one day some n00b uses run-time if-chains to create type-switch
>> (that doesn't work because it would CT-defined):
>> ...
>> if( typeof(a) == Foo)
>> ...
>> else if(typeof(a) == Bar)
>> ...
>>

> ...
> if(is(typeof(a) == Foo))
> ...
> else if(is(typeof(a) == Bar)(
> ...
>

Well that looks unnatural, noobs would have a reason to suspect something.

>> Though "code is unreachable" warning might help with it.
>
> Or any of the other compile time errors that is generated in the
> unreachable code because it cannot compile with the given parameters.
Except that type switch "usually" (if they could be counted as usual at all) followed by a cast to the said type. Think trash quality polymorphism.

-- 
Dmitry Olshansky

Timon Gehr:

> On 06/15/2012 02:19 PM, bearophile wrote:
>> Timon Gehr:
>>
>>> Why not allow equality operators to operate on types?
>>
>> That's nice, of course. But is it possible?
>>
>
> Yes, certainly.

OK. Then do you know why the nice improvement you suggest was not the design used since the beginning instead of is(==)?

Bye,
bearophile

On 6/15/2012 5:11 AM, Timon Gehr wrote:
> Why not allow equality operators to operate on types?

Generally because of parsing problems.

On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:
> On 06/15/2012 02:19 PM, bearophile wrote:
>> Timon Gehr:
>>
>>> Why not allow equality operators to operate on types?
>>
>> That's nice, of course. But is it possible?
>>
>
> Yes, certainly.

Not without losing the context insensitivity of the D grammar (because now we can't say for certain what "T == J" is until we semantically understand the program, but as it is now we understand it as comparing two values). That's a big thing to throw away, and this doesn't justify the change.

-Bernard.

Of course, "T == int" is unambiguous, but then when you can do that and not "T == J" you'll confuse people ("the compiler knows T and J are types...") and that rabbit hole is a dangerous one. Mainly because it makes parsing more difficult. I am nothing if not biased. :P