Typeof woes

Artur Skawina art.08.09 at gmail.com
Thu Aug 22 01:35:45 PDT 2013


On 08/21/13 02:43, H. S. Teoh wrote:
> On Wed, Aug 21, 2013 at 02:24:18AM +0200, Andrej Mitrovic wrote:
>> On 8/21/13, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
>>> and typeof(this.Smth) is invalid because this.Smth is already a
>>> type, so you can't apply typeof to it.
>>
>> I am beginning to wonder if typeof(typeof(expr)) is worthy of an
>> error. Would we end up having any bugs if we were to allow typeof() to
>> work on types (IOW it would just alias itself to the type)?
>>
>> I guess the only way to find out is to try it out in a compiler
>> branch, but I'm genuinely curious.
> 
> Hmm.
> 
> If typeof were idempotent on types, then it would provide nice closure
> properties (as in mathematical closure, not delegates) if we ever
> implement the proposed typetuple/std.typecons.Tuple unification from the
> other thread:
> 
> 	typeof(tup(1,"a")) == tup(int,string)
> 	typeof(tup(int,"a")) == tup(int,string)
> 	typeof(tup(int,string)) == tup(int,string)
> 
> This alleviates one of the nagging problems with mixed tuples that
> contain both types and expressions. Then the only left to do is to
> specify that a tuple can be used as a type only if it contains only
> types (IOW, if is(typeof(tup)==tup), a rather nice way to express it),
> and a tuple can be used as a value (assigned to variables, etc.) only if
> it contains only values.
> 
> "Mixed" tuples can still be used as template arguments, and you can
> always apply typeof to them.

You do realize that this is the way the built-in tuples work already?
With the exception of that last case, which of course is an error right
now. (I'm not sure that allowing typeof(Type) would be a good idea)

artur


More information about the Digitalmars-d-learn mailing list