Bug 242 – template implicit template properties doesn't work
Status
RESOLVED
Resolution
INVALID
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Linux
Creation time
2006-07-06T11:01:00Z
Last change time
2014-02-15T13:18:28Z
Keywords
rejects-valid
Assigned to
bugzilla
Creator
oskar.linde
Comments
Comment #0 by oskar.linde — 2006-07-06T11:01:28Z
template x() { template x() { const x = 1; } }
void main() { const y = x!()!(); }
Gives:
test.d(2): semicolon expected following auto declaration, not '!'
test.d(2): found '!' instead of statement
Instead, trying const y = x!().x!(), gives
test.d(2): template identifier x is not a member of x
I can't see any way to instantiate the inner template when it is "an implicit template property".
Comment #1 by wbaxter — 2006-11-28T09:43:27Z
(In reply to comment #0)
> template x() { template x() { const x = 1; } }
> void main() { const y = x!()!(); }
>
> Gives:
> test.d(2): semicolon expected following auto declaration, not '!'
> test.d(2): found '!' instead of statement
>
> Instead, trying const y = x!().x!(), gives
>
> test.d(2): template identifier x is not a member of x
>
> I can't see any way to instantiate the inner template when it is "an implicit
> template property".
>
Especially now with tuples, it would be nice if something like the x!()!() above worked. Because:
* A template can only have one tuple parameter.
* Multiple tuples passed into a tuple-taking template get merged into a single tuple.
Thus nested tuple templates seems to be the best hope for writing algorithms that process or combine multiple tuples.
template x(S...) { template x(T...) { /*use S and T together*/ } }
x!(int,float)!(3,24.0)
(And even if the inner one is not named x, you still can't do x!().y!() right now.)
Comment #2 by clugdbug — 2009-05-26T00:47:53Z
This is an enhancement.
Comment #3 by clugdbug — 2010-04-09T00:33:42Z
*** Issue 4061 has been marked as a duplicate of this issue. ***
Comment #4 by clugdbug — 2010-05-25T13:33:59Z
*** Issue 4233 has been marked as a duplicate of this issue. ***