www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - is as a type check

reply BCS <BCS_member pathlink.com> writes:
This is a feature suggestion. How about make "is" work on types (like for in
templates). For instance, if A and B are classes and C is derived from A, "(A is
B)" would be false and "(A is C)" would be true. It could also work on
variables, if d is of type A or C than "(d is A)" would be true and "(d is B)"
would be false. I think this looks more intuitive than cast(A)d.
Jul 05 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"BCS" <BCS_member pathlink.com> wrote in message 
news:daf1m0$vk8$1 digitaldaemon.com...
 This is a feature suggestion. How about make "is" work on types (like for 
 in
 templates). For instance, if A and B are classes and C is derived from A, 
 "(A is
 B)" would be false and "(A is C)" would be true. It could also work on
 variables, if d is of type A or C than "(d is A)" would be true and "(d is 
 B)"
 would be false. I think this looks more intuitive than cast(A)d.

Isn't this what the "IsExpressions" already do? Check out the "Expressions" section of the D spec, and look near the bottom.
Jul 05 2005
prev sibling parent reply Mike Capp <mike.capp gmail.com> writes:
In article <daf1m0$vk8$1 digitaldaemon.com>, BCS says...
This is a feature suggestion. How about make "is" work on types (like for in
templates). For instance, if A and B are classes and C is derived from A, "(A is
B)" would be false and "(A is C)" would be true. It could also work on
variables, if d is of type A or C than "(d is A)" would be true and "(d is B)"
would be false. I think this looks more intuitive than cast(A)d.

Given that D already uses 'is' for reference-object identity, I think this would break Walter's goal of an easily-parseable language. Given "foo is bar", the compiler wouldn't be able to tell whether "bar" is a variable or a type without looking at the symbol table, and AIUI this is something Walter wants to avoid. I quite like the "is" typecheck in C#, but then it's annoying having "Equals" and "==" do two completely different things in C#; D does a much better job here.
Jul 06 2005
parent Greg Smith <greg siliconoptix.com> writes:
Mike Capp wrote:

 In article <daf1m0$vk8$1 digitaldaemon.com>, BCS says...
 
This is a feature suggestion. How about make "is" work on types (like for in


 
 Given that D already uses 'is' for reference-object identity, I think this
would
 break Walter's goal of an easily-parseable language. Given "foo is bar", the
 compiler wouldn't be able to tell whether "bar" is a variable or a type without
 looking at the symbol table, and AIUI this is something Walter wants to avoid.
 

parse it. It needs to know at the semantic stage, but that is true already - consider 'a+b' where a,b are either two ints or two class objects, with overloaded +. Such issues already exist. If you look in the 'expressions' sections of the manual, there are two productions under which "(a).b" could be parsed, depending on whether 'a' is a type - but in practice the parser can treat these as the same thing and let the semantic analysis, which knows what 'a' is, sort it out. This is not at all the same as the situation in C, where, say, x = (foo)( a, bar()); has two very different meanings, requiring different parser behaviour, depending on whether 'foo' is a type. In order for the compiler to handle both cases, the parser needs to know wether to handle the (a,bar()) as a sequence operator ( if (foo) is a cast), or a parameter list to a function call. Another example, from C++, of the same token set having two valid but radically different meanings: typedef int foo; extern myclass bar; int x() { foo * p[2]; // defines a local variable, array of 2 ptrs to int bar * p[2]; // calls bar.operator * ( p[2] ) }
Jul 08 2005