www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why are statements not allowed in mixin templates?

reply Andrej Mitrovic <none none.none> writes:
If they're evaluated at the instantiation scope, and not in the point of
definition, then why are statements disallowed?

Where does the limitation come from?
Apr 09 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
 If they're evaluated at the instantiation scope, and not in the point of
 definition, then why are statements disallowed?
 
 Where does the limitation come from?

Probably because statements are only valid in functions, and a template is a set of declarations. It certainly wouldn't make any sense to have a normal template include statements, and the whole template mixin thing grew out of normal templates, so even if it makes perfect sense for template mixins to include statements, since they came out of normal templates in the first place (which can't have statements, since it would make no sense), they wouldn't wouldn't be able to have statements unless Walter thought to add that capabality specifically with mixing in in mind. But while templates that you mixin are generally designed for that and therefore designed differently than normal templates, I don't believe that there's any really difference in them except in how you instantiate them, so the compiler is going to end up treating them the same as far as the lexer and parser go. And since it makes no sense for normal templates to have statements, templates that you mixin don't either. But think of the mess that you'd have if you tried to instantiate a template as a normal template when it held statements? You'd probably get some pretty weird errors if that were allowed. So, I think that the limitation comes primarily from the fact that prior to mixins it made no sense for templates to contain naked statements, and templates intended for being used in mixins aren't really any different from normal templates from the compiler's perspective. - Jonathan M Davis
Apr 09 2011
prev sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
--0016e6dd8f44bcbb0a04a0843a60
Content-Type: text/plain; charset=ISO-8859-1

Couldn't you also just have your mixin define a function which - as a nested
function - would have access to the stack of the enclosing block?  Slightly
less pretty, and slightly different (since variables declared in the mixin
wouldn't exist in the enclosing scope)... ok, yeah, rather different.

On Sat, Apr 9, 2011 at 3:07 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 If they're evaluated at the instantiation scope, and not in the point of
 definition, then why are statements disallowed?

 Where does the limitation come from?

Probably because statements are only valid in functions, and a template is a set of declarations. It certainly wouldn't make any sense to have a normal template include statements, and the whole template mixin thing grew out of normal templates, so even if it makes perfect sense for template mixins to include statements, since they came out of normal templates in the first place (which can't have statements, since it would make no sense), they wouldn't wouldn't be able to have statements unless Walter thought to add that capabality specifically with mixing in in mind. But while templates that you mixin are generally designed for that and therefore designed differently than normal templates, I don't believe that there's any really difference in them except in how you instantiate them, so the compiler is going to end up treating them the same as far as the lexer and parser go. And since it makes no sense for normal templates to have statements, templates that you mixin don't either. But think of the mess that you'd have if you tried to instantiate a template as a normal template when it held statements? You'd probably get some pretty weird errors if that were allowed. So, I think that the limitation comes primarily from the fact that prior to mixins it made no sense for templates to contain naked statements, and templates intended for being used in mixins aren't really any different from normal templates from the compiler's perspective. - Jonathan M Davis

--0016e6dd8f44bcbb0a04a0843a60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Couldn&#39;t you also just have your mixin define a function which - as a n= ested function - would have access to the stack of the enclosing block? =A0= Slightly less pretty, and slightly different (since variables declared in t= he mixin wouldn&#39;t exist in the enclosing scope)... ok, yeah, rather dif= ferent.<br> <br><div class=3D"gmail_quote">On Sat, Apr 9, 2011 at 3:07 PM, Jonathan M D= avis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisPr= og gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">&gt; If they&#39;re evaluated at the instantiation scope,= and not in the point of<br> &gt; definition, then why are statements disallowed?<br> &gt;<br> &gt; Where does the limitation come from?<br> <br> </div>Probably because statements are only valid in functions, and a templa= te is a<br> set of declarations. It certainly wouldn&#39;t make any sense to have a nor= mal<br> template include statements, and the whole template mixin thing grew out of= <br> normal templates, so even if it makes perfect sense for template mixins to<= br> include statements, since they came out of normal templates in the first pl= ace<br> (which can&#39;t have statements, since it would make no sense), they would= n&#39;t<br> wouldn&#39;t be able to have statements unless Walter thought to add that<b= r> capabality specifically with mixing in in mind.<br> <br> But while templates that you mixin are generally designed for that and<br> therefore designed differently than normal templates, I don&#39;t believe t= hat<br> there&#39;s any really difference in them except in how you instantiate the= m, so<br> the compiler is going to end up treating them the same as far as the lexer = and<br> parser go. And since it makes no sense for normal templates to have<br> statements, templates that you mixin don&#39;t either. But think of the mes= s that<br> you&#39;d have if you tried to instantiate a template as a normal template = when it<br> held statements? You&#39;d probably get some pretty weird errors if that we= re<br> allowed.<br> <br> So, I think that the limitation comes primarily from the fact that prior to= <br> mixins it made no sense for templates to contain naked statements, and<br> templates intended for being used in mixins aren&#39;t really any different= from<br> normal templates from the compiler&#39;s perspective.<br> <font color=3D"#888888"><br> - Jonathan M Davis<br> </font></blockquote></div><br> --0016e6dd8f44bcbb0a04a0843a60--
Apr 09 2011