[Issue 24688] Parameter by-value keeps const (only in templates)
https://issues.dlang.org/show_bug.cgi?id=24688 --- Comment #2 from Dominikus Dittes Scherkl --- (In reply to Nick Treleaven from comment #1) > To do that, the compiler would have to analyse the body of the template > function. No. The strategy is - create a mutable copy (as it is done for normal functions) - only if this is not possible, create a const copy - if a const copy is neccessary, declare the template to take a const T (or, what I would recommend, take it by const ref T) --
[Issue 24688] Parameter by-value keeps const (only in templates)
https://issues.dlang.org/show_bug.cgi?id=24688 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- To do that, the compiler would have to analyse the body of the template function. Because T may be used to declare something that needs to be const in order for the function to compile, e.g. T*, T[]. --
[Issue 24688] New: Parameter by-value keeps const (only in templates)
https://issues.dlang.org/show_bug.cgi?id=24688
Issue ID: 24688
Summary: Parameter by-value keeps const (only in templates)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: domini...@scherkl.de
```d
int fun(int x) { return ++x; }
T tpl(T)(T x) { return ++x; }
main
{
const int i = 1;
const range r; // some type that cannot create mutable copies
int z = i; // works, the compiler makes a mutable copy
range s = r; // error **
z = fun(i); // works, the compiler makes a mutable copy
z = tpl(i); // error
}
```
The compiler should at least try to make a mutable copy also for templates.
If that is not possible, it should give the same error as in the line with **.
I'm ok if it instead tries a constant copy, but that should not be the default.
--
[Issue 19139] Need a convenient syntax for invoking nested eponymous templates
https://issues.dlang.org/show_bug.cgi?id=19139 basile-z changed: What|Removed |Added Summary|Need a convenient syntax|Need a convenient syntax |for invoking nested |for invoking nested |templates |eponymous templates --
[Issue 24523] writeln doesn't memoize its templates
https://issues.dlang.org/show_bug.cgi?id=24523 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@gmail.com Resolution|--- |WONTFIX Severity|normal |enhancement --- Comment #1 from Steven Schveighoffer --- Since write does exactly what is requested (loop over all parameters), it seems like the only "waste" here is a template instantiation of `write` with the particular parameters. Such a call is quite benign. See the code: https://github.com/dlang/phobos/blob/54eb95c139e09f6e7f8da3beed8407817ba184c1/std/stdio.d#L1750 And this also is going to result in extra instantiations of `write` (all the ones with single args). So in some cases, it may actually result in extra instantiations. In addition, splitting into multiple `write` calls is going to perform worse (and potentially cause weird outputs) as it locks and unlocks the underlying `File` for each parameter per call. Closing as wontfix. Now, there is a *runtime* penalty that is not discussed here. The fact that all the parameters need to be pushed again onto the stack, so you can add on the `\n`. If there was a better way to handle that, it might be useful to explore. Perhaps it's not worth fixing, because inlining might already do it. --
[Issue 24523] New: writeln doesn't memoize its templates
https://issues.dlang.org/show_bug.cgi?id=24523
Issue ID: 24523
Summary: writeln doesn't memoize its templates
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: crazymonk...@gmail.com
copy and pasted from the open d discord some messages:
as far as I understand, writeln is a variadic template, so for each set of
arguments you get a new instance of writeln in object code
--
I would expect a trivail optiomization here with how templates auto memoize
--
on practice, this generates a lot of garbage code
https://godbolt.org/z/9Gx6ja5vo
void main()
{
import std.stdio : writeln;
writeln("hello");
writeln(123);
writeln(123, 456);
}
--
it dups the template argument list 3 times
--
... why isnt writeln writen in such a way to auto memoize simplier write calls
its one line of code difference
--
wat?
--
```d
void writeln(S...)(S args)
{
write(args, '\n');
}
```
given grims code, write(int,int,string) and write(int,string) are both being
compiled
when it chould be
```d
void writeln(T...)(T args){
static foreach(a;args){write(a);}
write("\n");
}
```
and only compile write(int) and write(string)
---
I can't believe it, but monkyyy is actually correct on this one
https://godbolt.org/z/edf46vcqv
import std.stdio;
void smartWriteln(T...)(T args)
{
static foreach(a; args) { write(a);}
write("\n");
}
void a()
{
writeln(123, 345, 789);
smartWriteln(123, 345, 789);
}
---
etc.
writeln should be cleaned up and made to memoize arguments
--
[Issue 24479] [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479 --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16406 "Merge stable" was merged into master: - 9ca4c29549f944b820bbffc3e7b94c6f5ac23b1e by RazvanN7: Fix Bugzilla Issue 24479 - [REG2.104] Error on getAttributes on getOverloads of templates https://github.com/dlang/dmd/pull/16406 --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 --- Comment #9 from Dlang Bot --- dlang/dmd pull request #16406 "Merge stable" was merged into master: - ec25e56a93e1e6fbe9f3de1ab661cd0d40a82568 by Martin Kinkelin: Fix bugzilla 24505 - ImportC: Don't generate symbols for #undef'd macros https://github.com/dlang/dmd/pull/16406 --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dlang Bot --- dlang/dmd pull request #16398 "[stable] Fix bugzilla 24505 - ImportC: Don't generate symbols for #undef'd macros" was merged into stable: - 60ae79810cc3aaa6687dccdfe80553fc896bed8d by Martin Kinkelin: Fix bugzilla 24505 - ImportC: Don't generate symbols for #undef'd macros https://github.com/dlang/dmd/pull/16398 --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #7 from Iain Buclaw --- By the way, the documentation already covers this with the following workaround: ``` typedef struct stat stat_t; ``` https://dlang.org/spec/importc.html#tag-symbols --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 --- Comment #6 from Dlang Bot --- @kinke created dlang/dmd pull request #16398 "[stable] Fix bugzilla 24505 - ImportC: Don't generate symbols for #undef'd macros" fixing this issue: - Fix bugzilla 24505 - ImportC: Don't generate symbols for #undef'd macros https://github.com/dlang/dmd/pull/16398 --
[Issue 24479] [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16358 "Fix Issue 24479 - [REG2.104] Error on getAttributes on getOverloads of templates" was merged into stable: - 2e5d85a28ce1254f443b9bcd323c8d821cb8fed8 by RazvanN7: Fix Bugzilla Issue 24479 - [REG2.104] Error on getAttributes on getOverloads of templates https://github.com/dlang/dmd/pull/16358 --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @kinke created dlang/dmd pull request #16396 "[stable] Fix bugzilla 24505 - ImportC: Function-like macros may collide with regular symbols" fixing this issue: - Fix bugzilla 24505 - ImportC: Function-like macros may collide with regular symbols https://github.com/dlang/dmd/pull/16396 --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 --- Comment #4 from kinke --- (In reply to anonymous4 from comment #3) > Looks like a generic problem. How posix stat should work? It is a generic problem, one that we cannot solve elegantly in D/importC - we don't have an ugly 2-stage compilation like C(++), with preprocessor 'symbols'. But we need to be able to deal with this. In this concrete case, our interop code doesn't use `stat` in D at all, it's a totally uninteresting symbol, like ~99% of the C symbols dragged in by ~400k preprocessed lines. If one indeed depended on the `stat` macro, a solution could be to add a little wrapper in the .c file, letting the preprocessor do its magic, and then aliasing `stat` to that custom wrapper in the .d file importing the .c file. --
[Issue 21564] Allow assignment syntax for instantiating mixin templates
https://issues.dlang.org/show_bug.cgi?id=21564 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dmd pull request #16387 "Fix Bugzilla 21564 - assignment syntax for instantiating mixin templates" fixing this issue: - Fix Bugzilla 21564 - Allow assignment syntax for instantiating mixin templates Following the [alias this change](https://dlang.org/changelog/2.105.0.html#dmd.alias-this-syntax), I think mixin instantiation was the last place not using assignment syntax. https://github.com/dlang/dmd/pull/16387 --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505
--- Comment #3 from anonymous4 ---
Looks like a generic problem. How posix stat should work? It's defined as
struct stat { };
int stat(const char *pathname, struct stat *statbuf);
--
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 kinke changed: What|Removed |Added Keywords||industry --
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505
--- Comment #2 from kinke ---
The mixin template could work (the module is the .c file), but I doubt it'd be
a big improvement over simply ignoring a conflicting macro - as the importer
needs to know about such (potentially platform-dependant) header details, i.e.,
what symbol might be a macro.
Another manual solution could be to skip the translation if the macro is
undefined later via `#undef stat` - that would be doable in the .c file
including the headers, without having to patch the original headers.
Note that the Postgres header
(https://github.com/postgres/postgres/blob/master/src/include/port/win32_port.h)
is actually even a bit worse, defining 3 `stat` 'symbols':
```
#define stat microsoft_native_stat
#include
#undef stat
[…]
struct stat { … };
[…]
#define stat(path, sb) _pgstat64(path, sb)
```
--
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505
Tim changed:
What|Removed |Added
CC||tim.dl...@t-online.de
--- Comment #1 from Tim ---
Maybe macros and normal symbols could be in different modules or mixin
templates, so one is used by default, but it is still possible to get the other
symbol explicitly. An example lowering could be:
```
struct stat { int x; };
void __stat(int x, int y);
mixin template __CMacros()
{
// #define stat(x, y) __stat(x, y)
void stat(T1, T2)(T1 x, T2 y)
{
__stat(x, y);
}
}
mixin __CMacros!() __cmacros;
```
Now the compiler would prefer the struct, when using `stat`, but it would be
possible to get the macro using `__cmacros.stat`.
--
[Issue 24505] [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505 kinke changed: What|Removed |Added Keywords||ImportC --
[Issue 24505] New: [REG2.108] ImportC: Function-like macros (newly translated to templates) may collide with regular symbols
https://issues.dlang.org/show_bug.cgi?id=24505
Issue ID: 24505
Summary: [REG2.108] ImportC: Function-like macros (newly
translated to templates) may collide with regular
symbols
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ki...@gmx.net
This is a snippet derived from a Windows-specific Postgres header, which cannot
be imported with DMD v2.108 anymore:
```
struct stat { int x; };
void __stat(int x, int y);
#define stat(x, y) __stat(x, y)
```
```
Error: template `c.stat(__MP21, __MP22)(__MP21 x, __MP22 y)` conflicts with
struct `c.stat` at c.c(1)
```
I think it'd be better to skip the new macro-translation in such a case, maybe
with a printed warning. Alternatively, some ugly escape hatch via e.g.
`--ignore-macro=stat` - patching C headers isn't really a feasible option.
--
[Issue 8131] Delegate type inference with templates is absolutely *horrible*
https://issues.dlang.org/show_bug.cgi?id=8131 Nick Treleaven changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22501 --
[Issue 24479] [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @RazvanN7 updated dlang/dmd pull request #16358 "Fix Issue 24479 - [REG2.104] Error on getAttributes on getOverloads of templates" fixing this issue: - Fix Bugzilla Issue 24479 - [REG2.104] Error on getAttributes on getOverloads of templates https://github.com/dlang/dmd/pull/16358 --
[Issue 24479] [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Severity|major |regression --
[Issue 24479] [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #1 from Jonathan M Davis --- I would point out that making deprecations errors pretty much defeats their entire purpose vs just changing the code without a deprecation. They're supposed to inform you about code that you're going to need to change without immediately breaking your code. So, anyone compiling their code with -de is going to be getting errors when they're not supposed to - and it _will_ cause problems in some cases with generic code, because template constraints routinely test whether a particular piece of code compiles or not. Of course, regardless of how deprecations are treated, there then needs to be a way to transform your code appropriately so that it no longer triggers the deprecation, but deprecations are only treated as errors if you choose to do so, and it's usually a bad idea to do so. --
[Issue 24479] [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479 johanenge...@weka.io changed: What|Removed |Added Keywords||industry, rejects-valid --
[Issue 24479] New: [REG2.104] Error on getAttributes on getOverloads of templates
https://issues.dlang.org/show_bug.cgi?id=24479
Issue ID: 24479
Summary: [REG2.104] Error on getAttributes on getOverloads of
templates
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
Testcase, https://d.godbolt.org/z/cheqP1eof:
```
import std.meta : Filter;
struct S {
S opBinary(string op: "-")(S rhs) const pure nothrow @nogc {
return rhs;
}
S opBinary(string op: "*")(S dur) const pure nothrow @nogc {
return dur;
}
}
private enum hasExternalUDA(alias A) = is(A == External) || is(typeof(A) ==
External);
void foo() {
static foreach (t; __traits(getOverloads, S, "opBinary", true)) {
static assert( Filter!(hasExternalUDA, __traits(getAttributes,
t)).length == 0 );
}
static foreach (t; __traits(getOverloads, S, "opBinary", true))
static foreach(attr; __traits(getAttributes, t))
pragma(msg, attr);
static assert(__traits(getOverloads, S, "opBinary", true).length == 2);
alias A = __traits(getAttributes, __traits(getOverloads, S, "opBinary",
true)[1]);
}
```
Fails (deprecations are errors!) since dlang 2.104, with deprecations:
```
(16): Deprecation: `__traits(getAttributes)` may only be used for
individual functions, not overload sets such as: `opBinary`
(16):the result of `__traits(getOverloads)` may be used to
select the desired function to extract attributes from
(20): Deprecation: `__traits(getAttributes)` may only be used for
individual functions, not overload sets such as: `opBinary`
(20):the result of `__traits(getOverloads)` may be used to
select the desired function to extract attributes from
(24): Deprecation: `__traits(getAttributes)` may only be used for
individual functions, not overload sets such as: `opBinary`
(24):the result of `__traits(getOverloads)` may be used to
select the desired function to extract attributes from
```
Loosely related to https://issues.dlang.org/show_bug.cgi?id=23966.
I don't know a workaround, because iterating with explicit indexing as
suggested in 23966 also does not work (last line of testcase).
--
Re: Doubt about type Inference on templates
On Wednesday, 22 November 2023 at 19:37:58 UTC, Paul Backus wrote:
This is a bug/limitation in the compiler. I couldn't find an
existing report on issues.dlang.org, so I've reported it myself
as [issue 24255][1].
Wow: It is a very concise bug example.
I tested with ```ldc``` ant it fails too.
For now, I think the best way to work around it is to specify
the type in the lambda, as in `(int i) => i%2 == 0`.
agreed
The reason you see `void` is that when the compiler cannot
figure out the type of a function literal, it treats it as a
template function:
```d
static assert(__traits(isTemplate, i => i % 2 == 0));
```
And for silly historical reasons, when the compiler tries to
determine the type of a template, it returns `void` instead of
giving an error:
```d
template example() {}
static assert(is(typeof(example) == void)); // what??
```
Thanks Paul!!!
Re: Doubt about type Inference on templates
On Wednesday, 22 November 2023 at 17:53:15 UTC, Antonio wrote:
Basically, it doesn't know witch version of ```filter``` to
use, because it is inferring `i=>i%2==0` is `void` ?!?!?!
```
!()(IIterable!int, void)
```
If I explicitly write `(int i)=>i%2==0`, it compiles correctly
again.
**Is it mandatory to explicitly tell that `S` is `int` when
```IIterable!S source``` is `IIterable!int` alredy?**
This is a bug/limitation in the compiler. I couldn't find an
existing report on issues.dlang.org, so I've reported it myself
as [issue 24255][1].
For now, I think the best way to work around it is to specify the
type in the lambda, as in `(int i) => i%2 == 0`.
The reason you see `void` is that when the compiler cannot figure
out the type of a function literal, it treats it as a template
function:
```d
static assert(__traits(isTemplate, i => i % 2 == 0));
```
And for silly historical reasons, when the compiler tries to
determine the type of a template, it returns `void` instead of
giving an error:
```d
template example() {}
static assert(is(typeof(example) == void)); // what??
```
[1]: https://issues.dlang.org/show_bug.cgi?id=24255
Doubt about type Inference on templates
Just for fun, I'm trying to implement an alternative base library
to avoid template/mixin/static/traits code with only one
objective: make "intelliSense" code analyzers tasks easier.
I need "Generics"... but D has not generics: I use templates in
the "simplest" possible way
I.E.:
```d
interface IIterable(T)
{
bool empty();
void popFront();
T front();
}
IIterable!S toIterable(S)(S[] source)
=> new ArrayIterable!S(source);
IIterable!S filter(S)(IIterable!S source, bool delegate(S item)
predicate)
=> new Filter!S(source, predicate);
IIterable!S filter(S)(S[] source, bool delegate(S item) predicate)
=> toIterable(source).filter(predicate);
// ...
```
Then, in main.d I do
```d
import std.stdio;
void main(){
[1,2,3,4,5,6].toIterable!int.filter!int(i=>i%2==0).map!int(i=>i*2).toArray.writeln();
}
```
It works properly... until I remove the ```!int``` from the
```filter``` method.
```
main.d(3,38): Error: none of the overloads of template `filter`
are callable using argument types `!()(IIterable!int, void)`
iterable.d(21,13):Candidates are: `filter(S)(IIterable!S
source, bool delegate(S item) predicate)`
iterable.d(23,13):`filter(S)(S[] source,
bool delegate(S item) predicate)`
```
Basically, it doesn't know witch version of ```filter``` to use,
because it is inferring `i=>i%2==0` is `void` ?!?!?!
```
!()(IIterable!int, void)
```
If I explicitly write `(int i)=>i%2==0`, it compiles correctly
again.
**Is it mandatory to explicitly tell that `S` is `int` when
```IIterable!S source``` is `IIterable!int` alredy?**
[Issue 24242] forward inside templates with -dip1000 causes memory corruption
https://issues.dlang.org/show_bug.cgi?id=24242 --- Comment #4 from kinke --- (In reply to kinke from comment #3) > passing the array literal on the stack Well, allocating the array literal on the caller's stack and passing a slice to it. --
[Issue 24242] forward inside templates with -dip1000 causes memory corruption
https://issues.dlang.org/show_bug.cgi?id=24242 kinke changed: What|Removed |Added CC||ki...@gmx.net --- Comment #3 from kinke --- The problem appears to be that the compiler wrongly infers the `ulong[] value` ctor param as being `scope` (if the struct/ctor is templated). That then enables a (frontend) optimization, passing the array literal on the stack. --
[Issue 24242] forward inside templates with -dip1000 causes memory corruption
https://issues.dlang.org/show_bug.cgi?id=24242 Richard Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #2 from Richard Cattermole --- Swapping forward for move, stops the bug. Removing forward altogether also stops it. Going through the alias sequence inside of forward appears to prevent the compiler from being able to see that the function parameter value is used, and therefore can go on the stack. --
[Issue 24242] forward inside templates with -dip1000 causes memory corruption
https://issues.dlang.org/show_bug.cgi?id=24242 --- Comment #1 from Jan Jurzitza --- discovered bug conditions: - the variable holding data MUST be created in a separate function, creating it inline, e.g. in the `main` here, doesn't trigger the memory corruption - the struct MUST be templated for this bug to occur (otherwise it works as expected) --
[Issue 24242] New: forward inside templates with -dip1000 causes memory corruption
https://issues.dlang.org/show_bug.cgi?id=24242
Issue ID: 24242
Summary: forward inside templates with -dip1000 causes memory
corruption
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: d.b...@webfreak.org
minimal reproduction code:
```d
// bug.d
struct S()
{
ulong[] payload;
this(ulong[] value)
{
import core.lifetime;
payload = forward!value;
}
}
S!() test()
{
return S!()([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
}
void main()
{
import std.stdio;
auto val = test().payload;
writeln("[0]=", val[0], " (should be 0)");
writeln("[1]=", val[1], " (should be 1)");
writeln("[2]=", val[2], " (should be 2)");
writeln("[3]=", val[3], " (should be 3)");
writeln("[4]=", val[4], " (should be 4)");
writeln("[5]=", val[5], " (should be 5)");
writeln("[6]=", val[6], " (should be 6)");
writeln("[7]=", val[7], " (should be 7)");
writeln("[8]=", val[8], " (should be 8)");
writeln("[9]=", val[9], " (should be 9)");
}
```
`dmd -dip1000 -run source/app.d` (also happening with LDC)
causes:
```
[0]=0 (should be 0)
[1]=1 (should be 1)
[2]=140720508484016 (should be 2)
[3]=140720508484400 (should be 3)
[4]=14 (should be 4)
[5]=94655388051378 (should be 5)
[6]=94655388051378 (should be 6)
[7]=7 (should be 7)
[8]=4 (should be 8)
[9]=94655388051453 (should be 9)
```
real-world code: assign a `string[]` to mir-core's `Algebraic!(string[])`, the
strings will be messed up
note that everything works as expected without -dip1000
--
[Issue 23043] Visual D (VS 2022) project templates missing until configuration manually updated
https://issues.dlang.org/show_bug.cgi?id=23043 --- Comment #4 from dlangBugzillaToGithub --- THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/visuald/issues/256 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB --
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
Dennis changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||dkor...@live.nl
Hardware|x86_64 |All
Resolution|--- |INVALID
OS|Linux |All
--- Comment #7 from Dennis ---
Like FeepingCreature said, q{} is a string of D tokens, typically used for
string mixin purposes. dmd's behavior is correct. Please use a different string
literal kind for strings with code from other languages.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #6 from FeepingCreature ---
The easy solution would be writing `foo!"0b?01?11"`. `q{}` is intended for
fragments of D code.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032 --- Comment #5 from Puneet Goel --- Please ignore the previous comment. There was a mistake at my end. --
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #4 from Puneet Goel ---
Even if we have to do token parsing for q{}, the following code should not
fail.
class Foo(string str) {}
void main() {
Foo!q{string str = "0X"} foo;
Foo!q{string str = "0B"} bar;
}
The compiler gives the same errors as it gives for q{0B} and q{0X}.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #3 from Puneet Goel ---
I am using q{} to write my own DSL.
For this particular thing, I need to extend binary number strings in a way
where I can write stuff like 0b?01?11 where '?' can be used for pattern
matching. So, this becomes blocking for me. Is there an easy solution, or do I
need to discover an alternate syntax for my need?
BTW, what advantage do we gain by making the compiler parse q{} as a token
string?
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
--- Comment #2 from FeepingCreature ---
If you can replace the string with `q{0x0}`, that should work. Alternately,
pass a regular `"0x"` string.
--
[Issue 24032] Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #1 from FeepingCreature ---
Yes, Q{} is defined in the grammar as a "token string" which must consist of
valid D tokens, because it's meant to pass around fragments of source code.
"0X" stopped being a valid token in DMD 2.084.0:
https://dlang.org/changelog/2.084.0.html#deprecated_binary_literals
--
[Issue 24032] New: Compiler is parsing string parameters to Templates
https://issues.dlang.org/show_bug.cgi?id=24032
Issue ID: 24032
Summary: Compiler is parsing string parameters to Templates
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pun...@coverify.org
Works with dmd-2.081.2.
Error with dmd-2.085 and also with current release dmd-2.104
$ dmd /tmp/test.d
/tmp/test.d(3): Error: `0X` isn't a valid integer literal, use `0X0` instead
/tmp/test.d(4): Error: `0B` isn't a valid integer literal, use `0B0` instead
// test.d
class Foo(string str) {}
void main() {
Foo!q{0X} foo;
Foo!q{0B} bar;
}
--
[Issue 23946] specifications state that "there can only be one destructor" which can be confusing because of mixin templates
https://issues.dlang.org/show_bug.cgi?id=23946 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3636 "Fix Issue 23946 - spec states "there can only be one destructor"" was merged into master: - b70588595470372436c3f9b10ed91cb2cd3dc635 by Nick Treleaven: Fix Issue 23946 - specifications state that "there can only be one destructor" ...which can be confusing because of mixin templates https://github.com/dlang/dlang.org/pull/3636 --
[Issue 23946] specifications state that "there can only be one destructor" which can be confusing because of mixin templates
https://issues.dlang.org/show_bug.cgi?id=23946 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Severity|normal |minor --
[Issue 23946] specifications state that "there can only be one destructor" which can be confusing because of mixin templates
https://issues.dlang.org/show_bug.cgi?id=23946 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3636 "Fix Issue 23946 - spec states "there can only be one destructor"" fixing this issue: - Fix Issue 23946 - specifications state that "there can only be one destructor" ...which can be confusing because of mixin templates https://github.com/dlang/dlang.org/pull/3636 --
[Issue 23960] New: opApply and opApplyReverse should work with named mixin templates in aggregates
https://issues.dlang.org/show_bug.cgi?id=23960
Issue ID: 23960
Summary: opApply and opApplyReverse should work with named
mixin templates in aggregates
Product: D
Version: D2
Hardware: x86
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: witold.barylu...@gmail.com
https://godbolt.org/z/9qcGnWz8G
template M(int value) {
int opApply(scope int delegate(ref int i) dg) {
int v = value;
return dg(v);
}
}
struct S {
mixin M!5 m1;
mixin M!6 m2;
}
void main() {
import std.stdio : writefln;
S s;
foreach (i; s.m1) {
writefln("%d", i);
}
}
should compile and print 5.
But it does not compile:
dmd 2.094:
(16): Error: expression has no value
Compiler returned: 1
gdc trunk (14.0.0 20230530):
:16:3: error: invalid 'foreach' aggregate 's.mixin M!5 m1;
' of type 'void'
16 | foreach (i; s.m1) {
| ^
Compiler returned: 1
I discovered this problem when implementing intrusive circular double-linked
list, which I have two per Node (each node is a member of two intrusive
circular double-linked lists, each with prev and next pointers), where I wanted
to use opApply and opApplyReverse to traverse each list independently on
demand. I am implementation DLX algorithm (Knuth's Algorithm X brute force
depth-first backtracking algorithm for finding solutions to exact cover problem
using dancing links technique).
For opApply, it can be worked around using a delegate:
void main() {
import std.stdio : writefln;
S s;
foreach (i; ) {
writefln("%d", i);
}
}
but one cannot use `foreach_revserse` on delegates, instead one needs to use
`foreach` with `` which is less readable and restricts
usage. It also does not work well if there are many opApply and/or
opApplyReverse overloads, possibly templated, as then one cannot form delegate
without explicit instantiation.
Of course if there is only one unnamed mixin, it should be possible to still
use it via class/struct scope:
foreach (i; s), which will automatically find opApply
and if there are multiple, either ambiguity reported, or aliases uses to
provide an overload set. (This is already implemented in current D version).
--
[Issue 23946] specifications state that "there can only be one destructor" which can be confusing because of mixin templates
https://issues.dlang.org/show_bug.cgi?id=23946 Basile-z changed: What|Removed |Added Summary|specifications state that |specifications state that |"there can only be |"there can only be one |destructor" which can be|destructor" which can be |confusing because of mixin |confusing because of mixin |templates |templates --
[Issue 23946] specifications state that "there can only be destructor" which can be confusing because of mixin templates
https://issues.dlang.org/show_bug.cgi?id=23946 Basile-z changed: What|Removed |Added Summary|specifications state that |specifications state that |"there can only be |"there can only be |destructor" which can be|destructor" which can be |confusinf because of mixin |confusing because of mixin |templates |templates --
[Issue 23946] New: specifications state that "there can only be destructor" which can be confusinf because of mixin templates
https://issues.dlang.org/show_bug.cgi?id=23946
Issue ID: 23946
Summary: specifications state that "there can only be
destructor" which can be confusinf because of mixin
templates
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
§2 of https://dlang.org/spec/class.html#destructors states that "There can be
only one destructor per class, the destructor does not have any parameters, and
has no attributes. It is always virtual."
However this creates confusion as mixin templates are allowed to introduce a
destructor.
eg.
```
import std;
mixin template AddNewDtor()
{
~this()
{
writeln("Mixin dtor");
}
}
class Foo
{
~this()
{
writeln("Class dtor");
}
mixin AddNewDtor;
}
void main()
{
{
auto s = scoped!Foo;
// prints `Mixin dtor`
// prints `Class dtor`
}
}
```
The specifications should be more clear. While some might know that there are
the internal __dtor and __xdtor functions, the specs should mention that
"destructors introduced by mixin templates are implicitly called by the main
destructor and does not represent a real destructor" in
https://dlang.org/spec/template-mixin.html.
That's just a suggestion, any other solution that would prevent a possible
confusion for new comers is welcome.
See NG thread :
https://forum.dlang.org/post/czoaymnhawdtishtc...@forum.dlang.org
--
[Issue 9608] Add introspection for templates
https://issues.dlang.org/show_bug.cgi?id=9608 Vladimir Panteleev changed: What|Removed |Added CC||dlang-bugzilla@thecybershad ||ow.net --
[Issue 19780] `deprecated` is ignored on aliases of templates
https://issues.dlang.org/show_bug.cgi?id=19780 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- This seems to have been fixed. I am now getting: test.d(3): Deprecation: alias `test.MyTemplateAlias` is deprecated test.d(4): Deprecation: alias `test.NoTemplateAlias` is deprecated --
[Issue 20190] Deprecation not triggered on templates
https://issues.dlang.org/show_bug.cgi?id=20190 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from RazvanN --- I now get: test.d(5): Deprecation: template `test.Const(T)` is deprecated So this seems to have been fixed. --
[Issue 10892] Compilation continues after static assert failing in templates
https://issues.dlang.org/show_bug.cgi?id=10892 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN --- This issue is invalid. There is no order relationship between the declarations inside a template scope, so the expectation that the static assert is evaluated before the enum declaration is misguided. The general case is that the assert actually tests something that is defined inside the the template declaration scope, therefore we shouldn't expect a relationship order. --
[Issue 11095] mixed in mixin templates not handled as eponymous member
https://issues.dlang.org/show_bug.cgi?id=11095 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from RazvanN --- *** This issue has been marked as a duplicate of issue 1514 *** --
[Issue 1807] ENHANCEMENT: Let IFTI "see through" templates to simple aliases
https://issues.dlang.org/show_bug.cgi?id=1807 kdevel changed: What|Removed |Added CC||kde...@vogtner.de --
[Issue 1807] ENHANCEMENT: Let IFTI "see through" templates to simple aliases
https://issues.dlang.org/show_bug.cgi?id=1807 FeepingCreature changed: What|Removed |Added CC||default_357-l...@yahoo.de --- Comment #12 from FeepingCreature --- *** Issue 23798 has been marked as a duplicate of this issue. *** --
Re: templates and traits
On Saturday, 18 March 2023 at 20:42:50 UTC, Nick Treleaven wrote: On Saturday, 18 March 2023 at 19:22:07 UTC, Chris Katko wrote: ... So there's multiple sub-problems to solve. I asked this years ago, and got 90% of the way done and then lost the code and cannot find the original forum post. Maybe it was this?: https://forum.dlang.org/post/dqzxnctucwvyhstfz...@forum.dlang.org YES! I tried google search, forum search, even going through all my accounts posts, even my e-mail. I think I accidentally made that post without logging in so it's not attached to my account posts.
Re: templates and traits
On Saturday, 18 March 2023 at 19:22:07 UTC, Chris Katko wrote: ... So there's multiple sub-problems to solve. I asked this years ago, and got 90% of the way done and then lost the code and cannot find the original forum post. Maybe it was this?: https://forum.dlang.org/post/dqzxnctucwvyhstfz...@forum.dlang.org
templates and traits
Given:
```D
struct pos {float x, y;}
draw(myBitmap, pos(320, 240), centered);
draw(pos(320, 240), myBitmap);
draw("text", myFont, pos(320, 240));
```
I'm writing a general "draw" template function that through
compile-time, calls an associated DAllegro/Allegro 5 function:
```
draw(myBitmap, pos(320, 240), centered); //
al_draw_bitmap(myBitmap, pos.x - myBitmap.w/2, pos.y -
myBitmap.h, 0);
draw(pos(320, 240), myBitmap); // order doesn't matter
draw("text", myFont, pos(320, 240)); // different function
al_draw_text(...)
```
So there's multiple sub-problems to solve. I asked this years
ago, and got 90% of the way done and then lost the code and
cannot find the original forum post.
The pos(320,240) part works fine already. I need:
- At compile-time, for a variadic template that can take any
number of arguments, if specific arguments are available, I
branch and use them to call a specific applicable C function.
I remember I need to write some sort of enum function that checks
"IsAny" if an argument is passed at all, as well as one to find
where that argument is. Passing duplicates probably don't matter
(at least not right now), first valid argument is fine. I can't
seem to write code (or find example code online) that does this.
But it's something like
```D
enum isAny() = ...;
void draw(T...)(T)
{
if(isAny(bitmap))
{
// it's a sprite, now find out if we need it rotated,
stretched, etc.
}
is(isAny(string))
{
// its text [...]
}
}
```
A separate problem I've run into is, the 'centered' construct. If
I have rotate(25) (rotate 25 degrees), that works. But I cannot
just pass a type named "centered" with no variable attached to
it, nor can I--I think--pass an enum. I could do centered(false)
or centered(0), but that's clunkier than just saying "if
'centered' is an argument, we center it. If not, we don't." I
could have a variable named centered, I guess. or an enum with
{isCentered=1, notCentered=0} and detect if the enum is passed.
Lot's of ways to skin this cat.
The idea here, is I've got a lot of optional arguments (centered,
tinted, rotated, scaled, sheared, etc) that I can pick from and I
don't want to have to sort through a list of 80 different
permutations of function signatures, or, one gigantic
megafunction with a ton of zeros/nulls for all the unused
arguments.
This is a bit of a confusing problem to explain, so I've probably
left something necessary out.
[Issue 8961] IFTI fails with templates in specialization
https://issues.dlang.org/show_bug.cgi?id=8961 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- Lines 16 and 17 are now compile errors also. Lines 32 and 36 now compile without error. --
Combining Templates While Minimizing Bloat
The code below has two `foo` functions that take slices, one
accepts a const(T)* iterator and one accepts a generic Iterator
with the property that the slice isn't convertible to the first
one. The nice thing about this is that if you pass it with a
double* or const(double)*, then it doesn't increase template
bloat. The problem, however, is that I have to either have two
implementations or a separate `fooImpl` function to implement the
desired functionality. Is there any way to combine together the
`foo` functions in a way that maintains the template bloat
reducing behavior of the first function?
The example below uses mir, but it just as easily could be
adapted to other types.
```d
/+dub.sdl:
dependency "mir-algorithm" version="*"
+/
import std.stdio: writeln;
import mir.ndslice.slice;
void foo(T)(Slice!(const(T)*, 1) x)
{
writeln("here");
writeln("Iterator = ", typeid(IteratorOf!(typeof(x;
}
void foo(Iterator)(Slice!(Iterator, 1) x)
if (!is(Iterator : const(U)*, U))
{
writeln("there");
writeln("Iterator = ", typeid(IteratorOf!(typeof(x;
}
void main()
{
double[] x = [1.0, 2, 3];
auto y = x.sliced;
auto z = y.toConst;
foo(y); //prints "here" and "Iterator=const(double)*"
foo(z); //prints "here" and "Iterator=const(double)*"
auto a = y / 6;
foo(a); //prints "there" and "Iterator=(some long template
text)"
}
```
I tried something like
```d
void foo(Iterator)(Slice!(const Iterator, 1) x) {}
```
but this isn't a valid mir iterator since it becomes
const(double*) (a const pointer to a const double). What I need
is const(double)* (a mutable pointer to a const double).
[Issue 11095] mixed in mixin templates not handled as eponymous member
https://issues.dlang.org/show_bug.cgi?id=11095 Basile-z changed: What|Removed |Added CC||b2.t...@gmx.com Summary|mixed in mixin templates|mixed in mixin templates |not instantiated in |not handled as eponymous |templates |member --
[Issue 16707] [Templates] run variadic templates example failed
https://issues.dlang.org/show_bug.cgi?id=16707 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dlang.org pull request #3516 "Fix issue 16707" was merged into master: - 8f33642546b9163478e56d5f6a49ef8fbaae6015 by Drehuta Andreea: Fix issue 16707 https://github.com/dlang/dlang.org/pull/3516 --
[Issue 16707] [Templates] run variadic templates example failed
https://issues.dlang.org/show_bug.cgi?id=16707 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @AndreeaDrehuta created dlang/dlang.org pull request #3516 "Fix issue 16707" fixing this issue: - Fix issue 16707 https://github.com/dlang/dlang.org/pull/3516 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Dlang Bot --- dlang/dmd pull request #14838 "fix Issue 23598 - Circular reference bug with static if and eponymous…" was merged into master: - 9295ea950c3b1badc8662aff40b3ce868ff142cf by Walter Bright: fix Issue 23598 - Circular reference bug with static if and eponymous templates https://github.com/dlang/dmd/pull/14838 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23651 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Max Samukha changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23646 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #11 from Walter Bright --- Circular references that depend on the arms of a `static if` are always a likely source of chicken-egg problems. --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 --- Comment #10 from Dlang Bot --- @WalterBright created dlang/dmd pull request #14838 "fix Issue 23598 - Circular reference bug with static if and eponymous…" fixing this issue: - fix Issue 23598 - Circular reference bug with static if and eponymous templates https://github.com/dlang/dmd/pull/14838 --
[Issue 23598] Circular reference bug with static if and eponymous templates
https://issues.dlang.org/show_bug.cgi?id=23598 Walter Bright changed: What|Removed |Added Summary|Another nasty forward |Circular reference bug with |reference bug |static if and eponymous ||templates --
Re: How to Add CSS and JS to vibe.d templates
On 1/19/23 11:44 PM, seany wrote:
Hi
Howcan one add CSS and JS to vibe.d templates? Here is my setup (vibe.d
project initiated with dub using dub init myproject vibe.d):
./public:
main.css main.js
./source:
app.d
./views:
auth2fa.dt fail.dt login.dt pair.dt passfail.dt userfail.dt
I am trying to add a css file using `link(rel="stylesheet",
type="text/css", href="main.css")` in the diet templates, but it has no
effect. I took the files from here:
https://codepen.io/ricardoolivaalonso/pen/YzyaRPN
Keep in mind, this literally translates to a `link` tag in the HTML. So
here is what happens:
1. your vibe project is running, and passes out the compiled template to
the browser.
2. The browser sees the link tag, and attempts to ask the server for the
file "main.css"
3. The vibe project tries to match that to its routes, and cannot find
it, and so returns an error.
So this takes 2 steps to remedy:
1. Register a `serveStaticFiles` route with the glob `public/*`. See the
docs here: https://vibed.org/api/vibe.http.fileserver/serveStaticFiles
2. Change your link to refer to `public/main.css`, instead of just
`main.css`.
This is how it looks in my code:
```d
router.get("/public/*", serveStaticFiles(""));
```
And the links look like:
```pug
link(rel="stylesheet",href="/public/css/flatpickr.min.css")
```
as an example. Note that I put my css files into a css subdirectory
under public, and my javascript files under a js subdirectory. It all
depends on how you want to set it up.
-Steve
How to Add CSS and JS to vibe.d templates
Hi Howcan one add CSS and JS to vibe.d templates? Here is my setup (vibe.d project initiated with dub using dub init myproject vibe.d): ./public: main.css main.js ./source: app.d ./views: auth2fa.dt fail.dt login.dt pair.dt passfail.dt userfail.dt I am trying to add a css file using `link(rel="stylesheet", type="text/css", href="main.css")` in the diet templates, but it has no effect. I took the files from here: https://codepen.io/ricardoolivaalonso/pen/YzyaRPN Note that (as discussed in my previous post by Steven Schveighoffer) , there are some errors in the jade/pug template file. But even if we correct them, and then I try to use the setup, I do not get the styles. (Of course, i can't point my browser to www.my.server/main.css or so, because those endpoints are not defined. However, as I understood, all non-defined endpoints should anyway be redirected to public) Thank you.
[Issue 12298] Templates can be used in mixin even when not declared as mixin template
https://issues.dlang.org/show_bug.cgi?id=12298 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @RazvanN7 created dlang/dlang.org pull request #3479 "Fix Issue 12298 - Templates can be used in mixin even when not declared as mixin template" fixing this issue: - Fix Issue 12298 - Templates can be used in mixin even when not declared as mixin template https://github.com/dlang/dlang.org/pull/3479 --
[Issue 12298] Templates can be used in mixin even when not declared as mixin template
https://issues.dlang.org/show_bug.cgi?id=12298 --- Comment #2 from RazvanN --- *** Issue 16025 has been marked as a duplicate of this issue. *** --
[Issue 12191] bad purity propagation for double-nested delegate templates
https://issues.dlang.org/show_bug.cgi?id=12191 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 12298] Templates can be used in mixin even when not declared as mixin template
https://issues.dlang.org/show_bug.cgi?id=12298 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 11095] mixed in mixin templates not instantiated in templates
https://issues.dlang.org/show_bug.cgi?id=11095 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 8961] IFTI fails with templates in specialization
https://issues.dlang.org/show_bug.cgi?id=8961 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 12230] methods do not bind templates via alias parameter
https://issues.dlang.org/show_bug.cgi?id=12230 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 9948] -deps dependency printing incorrect for templates
https://issues.dlang.org/show_bug.cgi?id=9948 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 7825] Hijacking of functions by non-function templates.
https://issues.dlang.org/show_bug.cgi?id=7825 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 21921] DDOC: Using only the first function in templates with multiple functions
https://issues.dlang.org/show_bug.cgi?id=21921 Iain Buclaw changed: What|Removed |Added Priority|P3 |P4 --
[Issue 12216] Overloading templates using alias
https://issues.dlang.org/show_bug.cgi?id=12216 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 9721] Code coverage for templates
https://issues.dlang.org/show_bug.cgi?id=9721 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 11842] Operator overloading of named mixin templates
https://issues.dlang.org/show_bug.cgi?id=11842 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 11873] function templates conflict with aliases
https://issues.dlang.org/show_bug.cgi?id=11873 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 9922] Improve symbol emitting for templates for better separate compilation support
https://issues.dlang.org/show_bug.cgi?id=9922 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 12291] Pick up "this" from alias parameters to nested templates
https://issues.dlang.org/show_bug.cgi?id=12291 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 9608] Add introspection for templates
https://issues.dlang.org/show_bug.cgi?id=9608 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 11218] alias this and mixin templates should be interchangeable
https://issues.dlang.org/show_bug.cgi?id=11218 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 8407] Add inout inference to member functions in templates
https://issues.dlang.org/show_bug.cgi?id=8407 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 1807] ENHANCEMENT: Let IFTI "see through" templates to simple aliases
https://issues.dlang.org/show_bug.cgi?id=1807 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 19860] Memory corruption in nested templates
https://issues.dlang.org/show_bug.cgi?id=19860 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 20190] Deprecation not triggered on templates
https://issues.dlang.org/show_bug.cgi?id=20190 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 21891] Cannot alias every kind that can be passed via variadic templates
https://issues.dlang.org/show_bug.cgi?id=21891 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 13712] Templates don't resolve their static dtor order depending on passed in type
https://issues.dlang.org/show_bug.cgi?id=13712 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 18823] null is not shared as far as templates go
https://issues.dlang.org/show_bug.cgi?id=18823 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 19458] Speculatively-instantiated templates are incorrectly cached
https://issues.dlang.org/show_bug.cgi?id=19458 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
