www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - equality operators on types

reply Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Jun 15 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Jun 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 15 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.

all) followed by a cast to the said type. Think trash quality polymorphism. -- Dmitry Olshansky
Jun 15 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Why not allow equality operators to operate on types?

That's nice, of course. But is it possible? Bye, bearophile
Jun 15 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 07:19 AM, Bernard Helyer wrote:
 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

It is a comparison. That suffices for the parser. The grammar stays completely context-independent.
 until we semantically
 understand the program, but as it is now we understand it as comparing
 two values).

As it is now we don't know what it will do. import some.other.module; S a, b; bool c = a == b; /////// module some.other.module struct S{ bool opEquals(){ hardDrive.format(); assert(0); } }
 That's a big thing to throw away,

T[2] foo; auto b = foo[1]; // is this legal?
 and this doesn't justify the change.

 -Bernard.

I don't think this argument is valid.
Jun 16 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/17/2012 04:04 AM, Bernard Helyer wrote:
 Sigh. If you're going to reply like that, it would be nice to know you
 had the slightest fucking clue what you're talking about.

 On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:
 On 06/16/2012 07:19 AM, Bernard Helyer wrote:
 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

It is a comparison. That suffices for the parser. The grammar stays completely context-independent.

But we can't say whether T is a type or a value. _That_ matters.

FROM A PARSER LEVEL, NO!
Jun 16 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 07:24 AM, Bernard Helyer wrote:
 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

If done right, it makes parsing easier.
Jun 16 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 02:40 PM, Steven Schveighoffer wrote:
 On Sat, 16 Jun 2012 01:19:49 -0400, Bernard Helyer <b.helyer gmail.com>
 wrote:

 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.

Doesn't it already have to parse this today? I mean, is it the parser that decides T == J is invalid if T and J are types, or something later? It doesn't seem to me to be an issue with context insensitivity, if you have no context, you *already* can't know whether "T == J" is valid or not. By itself, T == J fits into D's grammar. Bitch-slap me if I'm wrong, I'm certainly not an expert in this here :) -Steve

You are right.
Jun 25 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jun 15 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2012 5:11 AM, Timon Gehr wrote:
 Why not allow equality operators to operate on types?

Generally because of parsing problems.
Jun 15 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 02:48 AM, Walter Bright wrote:
 On 6/15/2012 5:11 AM, Timon Gehr wrote:
 Why not allow equality operators to operate on types?

Generally because of parsing problems.

What kind of problems? All types fit into the expression grammar well enough. (pointer types should require parentheses in order to simplify parsing) The parser can already parse this: static if(int.min == (int*).min) { } It should be trivial to adapt it so that it can parse this: static if(int == (int*)) { } (in essence, stop requiring the scope resolution after everything that unambiguously looks like a type. The current behaviour is inconsistent anyway.)
Jun 16 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2012 4:37 AM, Timon Gehr wrote:
 On 06/16/2012 02:48 AM, Walter Bright wrote:
 On 6/15/2012 5:11 AM, Timon Gehr wrote:
 Why not allow equality operators to operate on types?

Generally because of parsing problems.

What kind of problems? All types fit into the expression grammar well enough. (pointer types should require parentheses in order to simplify parsing)

Perhaps it is possible if () are required, but one would have to carefully go through all the cases.
Jun 16 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2012 02:48 AM, Walter Bright wrote:
 On 6/15/2012 5:11 AM, Timon Gehr wrote:
 Why not allow equality operators to operate on types?

Generally because of parsing problems.

By the way, 'is' expressions are not immune to parsing issues: http://d.puremagic.com/issues/show_bug.cgi?id=6589
Jun 16 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
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.
Jun 15 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
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
Jun 15 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
Sigh. If you're going to reply like that, it would be nice to 
know you had the slightest fucking clue what you're talking about.

On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:
 On 06/16/2012 07:19 AM, Bernard Helyer wrote:
 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

It is a comparison. That suffices for the parser. The grammar stays completely context-independent.

But we can't say whether T is a type or a value. _That_ matters.
 import some.other.module;
 S a, b;
 bool c = a == b;

Again, from a parser level.
 ///////
 module some.other.module

 struct S{ bool opEquals(){ hardDrive.format(); assert(0); } }

FROM A PARSER LEVEL.
 That's a big thing to throw away,

T[2] foo; auto b = foo[1]; // is this legal?

FROM A PARSER LEVEL, YES. >_<
 I don't think this argument is valid.

Learn the difference between parsing valid and semantics, ffs.
Jun 16 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
Sorry, I'm being an asshole again. It's this newsgroup. It 
does... strange things to me. Apologies.
Jun 16 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 17, 2012 04:30:00 Timon Gehr wrote:
 On 06/17/2012 04:04 AM, Bernard Helyer wrote:
 Sigh. If you're going to reply like that, it would be nice to know you
 had the slightest fucking clue what you're talking about.
 
 On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:
 On 06/16/2012 07:19 AM, Bernard Helyer wrote:
 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

It is a comparison. That suffices for the parser. The grammar stays completely context-independent.

But we can't say whether T is a type or a value. _That_ matters.

FROM A PARSER LEVEL, NO!

It depends on the grammar. As it stands, with is(T == W), T and T must be types, and with T == W, they _cannot_ be types. If a different grammar rule were used inside of is, then you'd get a different result for what types of tokens the parser considers T and W to be. If you got rid of is(T == W) in favor of T == W, then the parser could no longer determine their types. That can certainly work - but only if the semantic analyzer is okay with the parser not knowing what T and W are. As it stands, IsExpression is its own rule in the grammar, and it expects T == W to be Type == TypeSpecialization, so the grammar rules are _defnitely_ different when == is used in an is expression is used than when == is used outside of an is expression. So, what you're suggesting would definitely mean changing the grammar, and it would mean giving the semantic analyzer less information from the parser (since it couldn't tell the semantic analyzer whether T and W were types or not). I expect that it's feasible, but it would be a large change. And one major downside would be that it would be impossible for a program which used the parser but not the semantic analyzer (e.g. for syntax highlighting) would then need the semantic analyzer as well to actually do what it does. - Jonathan M Davis
Jun 16 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Sunday, 17 June 2012 at 02:30:00 UTC, Timon Gehr wrote:
 On 06/17/2012 04:04 AM, Bernard Helyer wrote:
 Sigh. If you're going to reply like that, it would be nice to 
 know you
 had the slightest fucking clue what you're talking about.

 On Saturday, 16 June 2012 at 11:26:21 UTC, Timon Gehr wrote:
 On 06/16/2012 07:19 AM, Bernard Helyer wrote:
 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

It is a comparison. That suffices for the parser. The grammar stays completely context-independent.

But we can't say whether T is a type or a value. _That_ matters.

FROM A PARSER LEVEL, NO!

It absolutely would change the grammar (of the things I've written and the things I've studied). It may or may not change DMD's grammar, depending on whether it's over generalised -- I haven't looked. It's clear that you think it's not a change of any import, but I do.
Jun 16 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 16 Jun 2012 01:19:49 -0400, Bernard Helyer <b.helyer gmail.com>  
wrote:

 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.

Doesn't it already have to parse this today? I mean, is it the parser that decides T == J is invalid if T and J are types, or something later? It doesn't seem to me to be an issue with context insensitivity, if you have no context, you *already* can't know whether "T == J" is valid or not. By itself, T == J fits into D's grammar. Bitch-slap me if I'm wrong, I'm certainly not an expert in this here :) -Steve
Jun 25 2012