given tak.d:

import std.stdio;
void main()
{
//int[1][2]([3][4] i[5][6])[7][8];

    int i(I)(int){return 1;}
    writeln(typeof(i).stringof);
}

$ dmd tak && ./tak

spits out 'void'

does this make sense, or would it make more sense as an error for not appending the template argument? Or would it make more sense to include the template parameter in the string?

OT: without looking at compiler output, what is the type of the commented out i in d-style? :)

Ellery Newcomer wrote:
> given tak.d:
> 
> import std.stdio;
> void main()
> {
> //int[1][2]([3][4] i[5][6])[7][8];
> 
>     int i(I)(int){return 1;}
>     writeln(typeof(i).stringof);
> }
> 
> $ dmd tak && ./tak
> 
> spits out 'void'
> 
> does this make sense, or would it make more sense as an error for not appending the template argument? Or would it make more sense to include the template parameter in the string?
> 
> OT: without looking at compiler output, what is the type of the commented out i in d-style? :)

I'm kinda leaning towards your code as being an error,
after all without a template argument i isn't anything at all.
Why you get void as the result I suppose.

Or perhaps it's an infinite set of functions.

c.f.:

import std.stdio;

string templatesAreOdd(alias b)() {
	return b.stringof;
}

void main() {
    int i(I)(int){return 1;}
    alias i!(int)	foo;
    writeln(typeof(foo)(2).stringof);
    writeln(templatesAreOdd!(i));
}

That gives you the i(I) you might have been expecting.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Another question: given

import std.stdio;
void main()
{
    int i( /*char*/ ){return 1;}
    writeln(typeof(i).stringof);
}


This gives

(int())()

and with the char uncommented it errors

* typeof doesn't evaluate the expression, according to the spec.
* then why does it matter if the function has its parameters applied above?
* for a function sans params, there would be a semantic ambiguity (in D1
land, at least) in typeof(i) (params applied, or no?)
* and for the case above, why the heck are we mixing expression and type
in the string result?

On Fri, Nov 6, 2009 at 9:02 AM, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:
> Another question: given
>
> import std.stdio;
> void main()
> {
>    int i( /*char*/ ){return 1;}
>    writeln(typeof(i).stringof);
> }
>
>
> This gives
>
> (int())()

That seems buggy to me.  I would expect it to say "int".

> and with the char uncommented it errors

That seems right.  i by itself is an attempt to call i with no arguments.  You need to use & with functions if you want to avoid that.

> * typeof doesn't evaluate the expression, according to the spec.

But it is supposed to figure out what the type would be if it /were/ evaluated.

> * then why does it matter if the function has its parameters applied above?

"i" is a valid call in the first case, not in the second case.

> * for a function sans params, there would be a semantic ambiguity (in D1
> land, at least) in typeof(i) (params applied, or no?)

You need to use & if you're talking about the function itself and not what it evaluates to.

> * and for the case above, why the heck are we mixing expression and type in the string result?

I think that's a bug.  Does using &i give you the function type as expected?

--bb

Bill Baxter wrote:
> On Fri, Nov 6, 2009 at 9:02 AM, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:
>> Another question: given
>>
>> import std.stdio;
>> void main()
>> {
>>    int i( /*char*/ ){return 1;}
>>    writeln(typeof(i).stringof);
>> }
>>
>>
>> This gives
>>
>> (int())()
> 
> That seems buggy to me.  I would expect it to say "int".
> 
>> and with the char uncommented it errors
> 
> That seems right.  i by itself is an attempt to call i with no arguments.  You need to use & with functions if you want to avoid that.
> 
>> * typeof doesn't evaluate the expression, according to the spec.
> 
> But it is supposed to figure out what the type would be if it /were/ evaluated.
> 

Yeah, I suppose.

>> * for a function sans params, there would be a semantic ambiguity (in D1
>> land, at least) in typeof(i) (params applied, or no?)
> 
> You need to use & if you're talking about the function itself and not what it evaluates to.
> 

From my perspective in semantic analysis, &i doesn't refer to the function itself, it refers to a pointer to the function. I reckon that's kind of a weird nitpick..

>> * and for the case above, why the heck are we mixing expression and type in the string result?
> 
> I think that's a bug.  Does using &i give you the function type as expected?
> 

I didn't exactly expect a delegate, but yeah, that would be right.

okie dokie, semantic rule: functions must always either be applied or dereferenced in expressions.

except in template alias parameters. which is a special case anyways.

and regular aliases.

and who knows what else.


> --bb

On Fri, Nov 6, 2009 at 10:36 AM, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:
> Bill Baxter wrote:
>> On Fri, Nov 6, 2009 at 9:02 AM, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:
>>> Another question: given
>>>
>>> import std.stdio;
>>> void main()
>>> {
>>>    int i( /*char*/ ){return 1;}
>>>    writeln(typeof(i).stringof);
>>> }
>>>
>>>
>>> This gives
>>>
>>> (int())()
>>
>> That seems buggy to me.  I would expect it to say "int".
>>
>>> and with the char uncommented it errors
>>
>> That seems right.  i by itself is an attempt to call i with no arguments.  You need to use & with functions if you want to avoid that.
>>
>>> * typeof doesn't evaluate the expression, according to the spec.
>>
>> But it is supposed to figure out what the type would be if it /were/ evaluated.
>>
>
> Yeah, I suppose.
>
>>> * for a function sans params, there would be a semantic ambiguity (in D1
>>> land, at least) in typeof(i) (params applied, or no?)
>>
>> You need to use & if you're talking about the function itself and not what it evaluates to.
>>
>
> From my perspective in semantic analysis, &i doesn't refer to the function itself, it refers to a pointer to the function. I reckon that's kind of a weird nitpick..

Well, in D (and C) there's not really a difference because func is always a reference to some code, not the code itself.  There is no type which actually holds executable code.  Using & was just the device chosen to disambiguate given the no-parens function call syntax.  I could be wrong but I think in C you actually can use &func and func pretty much interchangeably.

>>> * and for the case above, why the heck are we mixing expression and type in the string result?
>>
>> I think that's a bug.  Does using &i give you the function type as expected?
>>
>
> I didn't exactly expect a delegate, but yeah, that would be right.

Yeh, inner functions have a hidden pointer to the outer function's stack frame.  So they're delegates.  I think you can make it static to prevent that.  Then it should be a plain function.

> okie dokie, semantic rule: functions must always either be applied or dereferenced in expressions.
>
> except in template alias parameters. which is a special case anyways.
>
> and regular aliases.
>
> and who knows what else.

You're right.  It is a bit messy.  Probably all those cases /should/ require &.

--bb