RejectedSoftware Forums

On Wed, 06 Feb 2013 21:50:36 GMT, Matej Nanut wrote:

I tried this:

- input(alias M)(string type /* ... */)
    input(id="#{M.stringof}", type="#{type}", value="#{M}" /* and so on */)

and I get an error saying "cannot use local 'varname' to non-global template".

That's a limitation of DMD right now, unfortunately. Maybe something like a global helper template

Tuple!(string, T) var(alias V, T) { return tuple(V.stringof, V); }

defined in a separate module would help a bit here. It wouldn't be as pretty, but the call could at least look like - input(var!varname, ...); instead of - input(varname, "varname", ...);.

That's too bad. I was hoping to combine this with UDAs, for example, and I'm fairly sure you need the aliased symbol for that.

Do you perhaps know what exactly the problem is? Is this going to be implemented in DMD or is it a design issue so it can't work?

Am 07.02.2013 13:45, schrieb Matej Nanut:

That's too bad. I was hoping to combine this with UDAs, for example, and I'm fairly sure you need
the aliased symbol for that.

Do you perhaps know what exactly the problem is? Is this going to be implemented in DMD or is it a
design issue so it can't work?

As far as I understood it's "only" an implementation problem: DMD works with a single context
pointer. Normally this will be this or a local delegate context pointer. But when a template is
defined inside of a function/class(*) and then a local variable is passed to it, it would need two
context pointers, one for the class/function scope (the template's scope) and one for the scope
where the variable lives in.

Originally the compiler accepted the code and silently failed by generating invalid code (causing
data corruption or linker errors). Instead of fixing/extending the compiler they chose to disallow
passing locals to local templates all together.

Passing local variables as aliases to global templates is still allowed, but it still can cause data
corruption. So I recommend to avoid that, too. I'll have to prepare a test case for this when I have
some time, as there currently is no open bug report for this AFAIK.

(*) All code in a Diet template is inserted into a function body as a technical necessity.

Am 07.02.2013 22:12, schrieb Dicebot:

On Thu, 07 Feb 2013 15:09:59 +0100, Sönke Ludwig wrote:

Passing local variables as aliases to global templates is still allowed, but it still can cause data
corruption. So I recommend to avoid that, too. I'll have to prepare a test case for this when I have
some time, as there currently is no open bug report for this AFAIK.

Are you sure about this? I have been doing this for ages in other code and had no problems if it is
the only context pointer needed. Any bugzilla / newsgroup link on topic?
Btw, Kenji had some proof-of-concept patch for allowing multiple context pointers, but,
unfortunately, discussion there stalled.

I know that with DMD 2.060 I still had data corruption in a project that used res.render!(), but
not with res.renderCompat!(). Kenji's fix for the original problem did seem to fix most of the
issues, but this seems to be a left-over. I haven't tried to reproduce it on 2.061 yet, but also
didn't see anything done in this area, so I assume that the issue persists.