I know this is an old issue, and I found this old bug to describe it (helping someone in a D.learn thread): http://d.puremagic.com/issues/show_bug.cgi?id=3464

But my question is, what is the value of T in *expected* usage.  The bug gives the example:

is(typeof(*T.init) == function)

to test for a function pointer, but I tried this:

is(main == function)

And that doesn't work, but this does:

is(typeof(main) == function)

So, my question is, what is typeof(main)?  I tried pragma(msg, typeof(main).stringof) and I get "void()()", which doesn't compile.

Given how ridiculously special-cased is expressions are anyways, can we just define is(T == function) to do something expected?  I can't think of a single "normal" use case that doesn't involve typeof or init.

I'd like to see either of these work instead of what we have:

is(main == function)
is(&main == function)

I think the latter would be the most useful, and consistent with delegates, especially since we got rid of declaring a function type (not function pointer type) in recent times (I think Don did this to prevent some kooky C legacy bug).

-Steve

On 02/10/2011 05:22 PM, Steven Schveighoffer wrote:
> I know this is an old issue, and I found this old bug to describe it (helping
> someone in a D.learn thread): http://d.puremagic.com/issues/show_bug.cgi?id=3464
>
> But my question is, what is the value of T in *expected* usage. The bug gives
> the example:
>
> is(typeof(*T.init) == function)
>
> to test for a function pointer, but I tried this:
>
> is(main == function)
>
> And that doesn't work, but this does:
>
> is(typeof(main) == function)
>
> So, my question is, what is typeof(main)? I tried pragma(msg,
> typeof(main).stringof) and I get "void()()", which doesn't compile.

???
We need types to exist, not typeof's.

> Given how ridiculously special-cased is expressions are anyways, can we just
> define is(T == function) to do something expected? I can't think of a single
> "normal" use case that doesn't involve typeof or init.
>
> I'd like to see either of these work instead of what we have:
>
> is(main == function)
> is(&main == function)
>
> I think the latter would be the most useful, and consistent with delegates,
> especially since we got rid of declaring a function type (not function pointer
> type) in recent times (I think Don did this to prevent some kooky C legacy bug).

Agreed. This would be a step toward stopping function* implementation detail leaking into language semantics. The language feature <function> should just mean function. (Else, to be consistent, we should be forced to use delegate pointers as well, no?)

If can stop and using '&' to pass functions as arguments, then life is good and we should use is(main == function). Else, vote rather for is(&main == function) as well, for better consistency.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com