Bruno Medeiros wrote:
> Don Clugston wrote:
>> Sean Kelly wrote:
>>> Bruno Medeiros wrote:
>>>> Sean Kelly wrote:
>>>>> Hasan Aljudy wrote:
>>>>>> I don't know if this is a bug or what, but for some reason, dmd allows you to define classes/structs/unions/enums as statements inside function bodies.
>>>>>> Oddly enough, you cannot define a template in the same way
>>>>>>
>>>>>> I didn't find in the docs any mention of whether aggregates are allowed inside function bodies or not.
>>>>>>
>>>>>> Walter, is this the correct behaviour?
>>>>>
>>>>> It is.  Templates are merely a special case as they must have external linkage.
>>>>
>>>> What do you mean by that? What is external linkage? Did you meant an extern(al) storage class? (I just found out now something I unknew, that are two distinct "extern" keywords/concepts in D)
>>>> And how exactly does that restricts templates not being allowed inside functions?
>>>
>>> External linkage means that a symbol is visible from another module. But I mis-spoke.  Template parameters must have external linkage. Templates themselves may only be defined at module or class scope.  This is a carryover from C++, and I'm not certain whether there's a technical obstacle to function-scope templates or not.  There doesn't seem to be, but then I've never implemented template support in a compiler before. Perhaps Walter could explain further.
>>
>> There's some weird stuff in there. Mixins can be local, and because of alias template parameters, there's a name mangling for templates which are defined local to functions.
> 
> There are no templates *defined* local to functions. Did you mean mixin instantiations?

Yes, sorry.

> I think (normal) template instances are quite different from mixin instances in that regard. Mixin instances have copy-paste behaviour and are each unique, and the mixin name part has no name-magling at all in the case of an anonymous mixin, or has the name which is defined in the named mixin. 

Curiously, this isn't the whole story. There's a mangled name (difficult to access) which includes the name of the function that the mixin is defined in, and it includes the template arguments that were used -- it's almost the whole mechanism that you'd expect for templates which are local to functions. It's completely undocumented, of course.


(Normal) template instances have name-mangling dependent on
>  the template arguments, because that is what _identifies_ the template instance. There is no such parallel with mixins, as they are unique.
> I can't test any of these suppositions yet, as I can't check the .obj's symbols or ASM (I'm planning to get the EUP soon), but I'm fairly sure it's something more or less like this. 

Don Clugston wrote:
> Bruno Medeiros wrote:
>> Don Clugston wrote:
>>> Sean Kelly wrote:
>>>> Bruno Medeiros wrote:
>>>>> Sean Kelly wrote:
>>>>>> Hasan Aljudy wrote:
>>>>>>> I don't know if this is a bug or what, but for some reason, dmd allows you to define classes/structs/unions/enums as statements inside function bodies.
>>>>>>> Oddly enough, you cannot define a template in the same way
>>>>>>>
>>>>>>> I didn't find in the docs any mention of whether aggregates are allowed inside function bodies or not.
>>>>>>>
>>>>>>> Walter, is this the correct behaviour?
>>>>>>
>>>>>> It is.  Templates are merely a special case as they must have external linkage.
>>>>>
>>>>> What do you mean by that? What is external linkage? Did you meant an extern(al) storage class? (I just found out now something I unknew, that are two distinct "extern" keywords/concepts in D)
>>>>> And how exactly does that restricts templates not being allowed inside functions?
>>>>
>>>> External linkage means that a symbol is visible from another module. But I mis-spoke.  Template parameters must have external linkage. Templates themselves may only be defined at module or class scope.  This is a carryover from C++, and I'm not certain whether there's a technical obstacle to function-scope templates or not.  There doesn't seem to be, but then I've never implemented template support in a compiler before. Perhaps Walter could explain further.
>>>
>>> There's some weird stuff in there. Mixins can be local, and because of alias template parameters, there's a name mangling for templates which are defined local to functions.
>>
>> There are no templates *defined* local to functions. Did you mean mixin instantiations?
> 
> Yes, sorry.
> 
>> I think (normal) template instances are quite different from mixin instances in that regard. Mixin instances have copy-paste behaviour and are each unique, and the mixin name part has no name-magling at all in the case of an anonymous mixin, or has the name which is defined in the named mixin. 
> 
> Curiously, this isn't the whole story. There's a mangled name (difficult to access) which includes the name of the function that the mixin is defined in, and it includes the template arguments that were used -- it's almost the whole mechanism that you'd expect for templates which are local to functions. It's completely undocumented, of course.
> 
> 

Hum curious indeed, I wonder what it's for.
In any case I don't think there is any problem in creating a mangled name from a local alias argument. As long as an argument has a fully-qualified name, it can be mangled I believe, and even local variables have FQNs.
The restriction is likely instead that a (normal)template instance simply cannot access the frame of the parent function of the argument (just like the error message says), so a local argument can't be used.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D