• BCS (5/5) Jul 05 2005 This is a feature suggestion. How about make "is" work on types (like fo...
• Jarrett Billingsley (4/12) Jul 05 2005 Isn't this what the "IsExpressions" already do?
• Mike Capp (8/13) Jul 06 2005 Given that D already uses 'is' for reference-object identity, I think th...
• Greg Smith (26/35) Jul 08 2005 IFAICT, the compiler doesn't need to know which it is in order to

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.

"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. 

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.



here.

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.
 

IFAICT, the compiler doesn't need to know which it is in order to
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] )
}