On 22/05/2011 21:51, Timon Gehr wrote:
<snip>
I suspect what Andrej actually meant is to kill treating function
signatures as types in this way. And possibly "enhancement
request" rather than "bug".
It is the opposite of an enhancement request. It means removing a
feature that cannot be meaningfully substituted by other features.
Unless you know a use case I've never heard of, it's no more "a feature that cannot be
meaningfully substituted by other features" than the C preprocessor.
(also, removing it increases the inconsistency of the language and
makes the compiler more complex).
I disagree. My point is that function types and data types have practically nothing in
common. So your argument seems to me like claiming that D is inconsistent because classes
and functions aren't interchangeable.
<snip>
True, if you use "type" in a broad sense. But it doesn't declare
a variable of that type, and you can't use it as a type as such.
Really, function signatures and data types are distinct entities
and ought not to be interchangeable.
You can alias any symbol. Data types and other symbols are
distinct entities too. By your arguments, this is a bad thing to
have.
But do function signatures count as symbols? I'm not sure.
Also, a function signature, while not a data type is still a _type_
(the "broad sense" is the D sense. You can do
typeof(some_function)).
And do what _with_ it, let alone that cannot be done by any other means?
<snip>
alias int func();
int main(){
static assert(is(typeof(main)==func);
alias int function() func;
static assert (is(typeof(&main) == func));
return 0;
}
I do not get why anybody would want to remove the possibility to
refer to function signatures. It can be handy for template
constraining.
<snip>
Can you give an example?
Stewart.
