View mode: basic / threaded / horizontal-split · Log in · Help
July 05, 2005
is as a type check
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.
July 05, 2005
Re: is as a type check
"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.
July 06, 2005
Re: is as a type check
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.
July 08, 2005
Re: is as a type check
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] )
}
Top | Discussion index | About this forum | D home