typeof and my crummy code...

[Bill Baxter]

On Fri, Nov 6, 2009 at 10:36 AM, Ellery Newcomer
<ellery-newcomer at utulsa.edu> wrote:
> Bill Baxter wrote:
>> On Fri, Nov 6, 2009 at 9:02 AM, Ellery Newcomer
>> <ellery-newcomer at 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