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
