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.

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

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.

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] )
}