On Mon, 23 May 2011 10:50:11 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Since &main can't be a template value argument, maybe he meant this use case:
>
> alias int func();
>
> void foo(alias T)()
> {
      static assert(is(typeof(&T) == int function())); // fixed
> }
>
> int main()
> {
>     foo!main;
>     return 0;
> }

Nice.

Steven Schveighoffer wrote:
> On Mon, 23 May 2011 10:50:11 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> Since &main can't be a template value argument, maybe he meant this use case:
>>
>> alias int func();
>>
>> void foo(alias T)()
>> {
>       static assert(is(typeof(&T) == int function())); // fixed
>> }
>>
>> int main()
>> {
>>     foo!main;
>>     return 0;
>> }

Oh, I am sorry. I did not realize that D does not allow overloading the address-of operator. (C++ does, but D is quite restrictive, I have to get used to that) Therefore, this solution works of course unambiguously.

Well, you could kill alias R func(T); in that case, but still, it makes the
compiler more complicated. :)

Maybe you even want to kill typeof(some_function) then? I think that, without being able to refer to function types per alias, this could often be a bug.

Timon

On Mon, 23 May 2011 14:06:31 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 23 May 2011 10:50:11 -0400, Andrej Mitrovic
>> <andrej.mitrovich@gmail.com> wrote:
>>
>>> Since &main can't be a template value argument, maybe he meant this use
>>> case:
>>>
>>> alias int func();
>>>
>>> void foo(alias T)()
>>> {
>>       static assert(is(typeof(&T) == int function())); // fixed
>>> }
>>>
>>> int main()
>>> {
>>>     foo!main;
>>>     return 0;
>>> }
>
> Oh, I am sorry. I did not realize that D does not allow overloading the address-of
> operator. (C++ does, but D is quite restrictive, I have to get used to that)
> Therefore, this solution works of course unambiguously.
>
> Well, you could kill alias R func(T); in that case, but still, it makes the
> compiler more complicated. :)

I went to Don's thread to give you a good case of why it's worth it, and I realized that his example looks nothing like what yours does, and in fact, is disallowed in the latest compiler.  So we have been talking about two completely different problems.

The issue was for C-style function type declarations:

int x;
x(y); // declare a function type y which returns an x, but looks like a function call.

Here was the bug report:  http://d.puremagic.com/issues/show_bug.cgi?id=4987

So although I think the alias function syntax is horrible, it's not nearly as bad as I thought.  I also still don't see much use for it, it seems much more straightforward to use function pointers as types instead.  I'd favor removing it, but I was wrong that it was already scheduled to be removed.

-Steve

On 23/05/2011 07:43, David Nadlinger wrote:
> On 5/23/11 8:41 AM, Andrej Mitrovic wrote:
<snip>
>> What's wrong with using this:
>>
>> alias void function(int, int) funcAlias;
>
> It's a function pointer type, not a function type.

How is that something wrong with it?  I.e. what can you do with a function type that you cannot possibly do by using the function pointer type instead?

Stewart.

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.