Thread overview | ||||||
---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Capp | 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] ) } |
Copyright © 1999-2021 by the D Language Foundation