is() syntax (Re: operator new(): struct v. class)

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Fri Sep 7 09:07:47 PDT 2007


Don Clugston wrote:

> Kirk McDonald wrote:
>> Bill Baxter wrote:
>>> And why do we even need is() to do basic type comparisons anyway?
>>> What's ambiguous about
>>>    static if( MyType == OtherType ) {
>>>         ...
>>>    }
>>> ?
>>> I guess you could define a static opEquals, but A) that's useless
>>> enough that it could be outlawed B) it wouldn't take a type as an
>>> argument so it still wouldn't be ambiguous.
>>>
>>> --bb
>> 
>> It is ambiguous. Both sides of a comparison must be an expression, and
>> types are not expressions. Allowing that would mean you couldn't
>> determine whether 'MyType' is an expression or a type until after the
>> syntactic pass. This would break some cardinal rules about the ease with
>> which you can parse D code.

Even now you can't tell whether e.g. 'a = b' is syntactically correct
without several passes of semantic analysis:

template z(string x, string y){mixin(`mixin("template c(string
T){mixin(\"alias \"~T~\" t;\");}");c!("int").t `~x~`; int s(
string a) { return a.length ? 1 + s(a[1..$]) : 0; } auto `
~y~`= s(x~y);`);}mixin z!("a","b"); void main() {

  a = b;

}

> 
> Ideally, I think, we'd have a merge between is() and typeof()/typeid()
> static if (typeid(MyType)==typeid(OtherType)) {
> }

I find the idea of comparing types directly more natural. Compile time
metaobjects feel really intriguing in general. However, I feel sorry for
Walter. Implementing all this some day must be tiresome :)

> There are quite a few cases where we have syntax which is completely
> different at run-time compared to compile compile-time, yet which do
> exactly the same thing. __traits and typeinfo seem to be awfully similar,
> for example.

If one the main design principles of D was the principle of least surprise,
is expression would have been buried long time ago. Honestly, it has one of
the weirdest syntax and semantics.

> If they were unified, CTFE could grab even more territory 
> from templates.

As long as CTFE and/or string mixins can't handle alias parameters there
will be need for templates (and/or macros).



More information about the Digitalmars-d mailing list