question...

Robert DaSilva sp.unit.262+digitalmars at gmail.com
Thu Jan 10 15:56:05 PST 2008


Aarti_pl wrote:
> Aziz K. pisze:
>> Marcin Kuszczak wrote:
>>> Thanks for explanation. But I think that something is wrong here anyway.
>>> Please see first example. 'A' is also not expression, but it compiles
>>> properly. Maybe it would not be a big problem to extend typeof in such a
>>> way that it can accept types also.
>>>
>>
>> This is the example:
>> class A {}
>> static assert(is( typeof(new A) == typeof(A)) ); // 1
>>
>> The 'A' in typeof is an expression. Of course a human reader can see
>> that it actually is a type (class A), but to a D parser it is an
>> "Expression" because that's what the grammar rules say. Only when the
>> semantic pass is started, identifiers can be resolved to the symbol
>> they refer to, which could be a variable, a function, a class, a type
>> etc.
>> That means, what an identifier in an Expression actually is can only
>> be determined in the semantic phase. But on the other hand,
>> identifiers in "Types" must always refer to type symbols (if they
>> don't, it's a semantic error.)
>> In short, depending on the syntax tree produced in the parsing phase:
>>   * in a Type tree, identifiers must refer to classes, structs,
>> aliases, typedefs etc.
>>   * in an Expression tree, identifiers can be anything.
>>
>> You suggested to extend typeof to allow Types as well. I don't think
>> that's a good idea and I think it's not going to happen (ie. Walter
>> won't implement it.) The reason is that typeof has one perfect
>> purpose, that is to get the type of an expression. I don't see any
>> sense in passing a Type to typeof in order to get what you had in the
>> beginning anyway. Maybe there could be a legitimate use-case for this,
>> but I'd like to see convincing examples where this would be meaningful
>> and useful.
>>
>> Regards,
>> Aziz
> 
> Well, even greater explanation :-) Thanks! Now I understand why it works
> like that.
> 
> Nevertheless I still think that I should look at DMD front end from user
> point of view. I will probably never understand compiler arcana as good
> as e.g. Walter, so it's probably not my job to think about it from this
> perspective.
> 
> And from user point of view I would still argue that it is kind of bug.
> Something what is very similar from user point of view behaves
> completely different: 'A' is a type, and int is a type, so it should
> behave similarly.
> 
> You asked for use case. There is one (very simple, well, even simplistic
> :-) )
> 1. Duplicate line with expression typeof(A)
> 2. Change A to int
> 3. Get surprised by unexpected and error
> 
> --------------
> 
> I see following possibilities:
> 1. Improve error message, which is completely unhelpful
> 2. Allow simple types in typeof()
> 
> Please notice that when Walter choose first option, he has a really
> tough job to explain in short error message why there can be type 'A',
> but there can not be int.
> 
> I completely agree that this bug/enhancement has low priority. But I
> hope you see some merits in what I have written.
> 
> I will put it as enhancement request on bugzilla. With low priority... :-)
> 
> BR
> Marcin Kuszczak
> (aarti_pl)

There already is.
http://d.puremagic.com/issues/show_bug.cgi?id=1341


More information about the Digitalmars-d-learn mailing list