Note that this doesn't work in gdc.
The templated version is actually more akin to what C does.
Yeah it does not seem to work in gdc when tested using
https://d.godbolt.org/
The errors produced:
```
:11:12: error: none of the overloads of template
'core.stdc.stdarg.va_arg' are callable us
On 9/15/23 4:14 PM, Basile B. wrote:
On Thursday, 14 September 2023 at 15:19:29 UTC, BoQsc wrote:
https://dlang.org/phobos/core_vararg.html
The common way to use **va_arg** is `va_arg!(int)(_argptr);`
What would be the alternative way or syntax that behave exactly the
same way, even if more ve
On Thursday, 14 September 2023 at 15:19:29 UTC, BoQsc wrote:
https://dlang.org/phobos/core_vararg.html
The common way to use **va_arg** is `va_arg!(int)(_argptr);`
What would be the alternative way or syntax that behave exactly
the same way, even if more verbose?
`va_arg!(int)(_argptr)
https://dlang.org/phobos/core_vararg.html
The common way to use **va_arg** is `va_arg!(int)(_argptr);`
What would be the alternative way or syntax that behave exactly
the same way, even if more verbose?
`va_arg!(int)(_argptr);` is taken from an example in:
https://dlang.org/spec/functio
On Sunday, 9 July 2023 at 14:49:39 UTC, Steven Schveighoffer
wrote:
This is probably a bug somewhere, 4 seconds is too much. A
reduced test case would be helpful.
But I wanted to note, inside a struct template, the template
name (by itself) is equivalent to the current instantiation. So
jus
On 7/9/23 7:54 AM, IchorDev wrote:
While working on some new bindings, I've discovered that if `opAssign`
in a struct template "`BindingTempl(T)`" has the return type
"`BindingTempl!T` then it adds about 4 seconds to the compile time per
instantiation of `BindingTempl`. The added compile time i
While working on some new bindings, I've discovered that if
`opAssign` in a struct template "`BindingTempl(T)`" has the
return type "`BindingTempl!T` then it adds about 4 seconds to the
compile time per instantiation of `BindingTempl`. The added
compile time is much lower if a function other th
On Friday, 31 December 2021 at 12:36:46 UTC, H. S. Teoh wrote:
```
void lyr(alias Fn)(ref R r)
{
Fn(r);
}
```
Thanks! That helped me reinvent the engine.
On Fri, Dec 31, 2021 at 11:52:21AM +, kdevel via Digitalmars-d-learn wrote:
[...]
> That is what I want to do. The function template lyr shall be
> (explicitly) instantiated in order to put the resulting function
> pointer into an AA. The call signature of lyr!(foo) and foo must be
> the same.
On Friday, 31 December 2021 at 09:01:10 UTC, data pulverizer
wrote:
On Friday, 31 December 2021 at 00:57:26 UTC, kdevel wrote:
Pointers are runtime entities and are not suitable template
parameters (compile time).
The address of a function does not change at runtime. The
question is: Can func
On Friday, 31 December 2021 at 03:02:08 UTC, Tejas wrote:
[...]
Is it okay to use template parameter instead of **template
value** parameter?
```d
class R {
}
void foo (R r)
{
}
void lyr (fp_type, R) (fp_type fp, R r)
{
}
pragma (msg, typeof (&foo));
R r;
void main(){
auto foo_ptr = &foo;
On Friday, 31 December 2021 at 00:57:26 UTC, kdevel wrote:
```dptr.d
class R {
}
void foo (R r)
{
}
alias fn = void function (R);
void lyr (fn F) (R r)
{
}
immutable fn foo_ptr = &foo; // line 14
pragma (msg, typeof (foo_ptr));
auto ptr = lyr!(foo_ptr);// line 17
```
dmd reports:
```
im
On Friday, 31 December 2021 at 00:57:26 UTC, kdevel wrote:
```dptr.d
class R {
}
void foo (R r)
{
}
alias fn = void function (R);
void lyr (fn F) (R r)
{
}
immutable fn foo_ptr = &foo; // line 14
pragma (msg, typeof (foo_ptr));
auto ptr = lyr!(foo_ptr);// line 17
```
dmd reports:
```
im
```dptr.d
class R {
}
void foo (R r)
{
}
alias fn = void function (R);
void lyr (fn F) (R r)
{
}
immutable fn foo_ptr = &foo; // line 14
pragma (msg, typeof (foo_ptr));
auto ptr = lyr!(foo_ptr);// line 17
```
dmd reports:
```
immutable(void function(R))
dptr.d(14): Error: expression `& f
On Thursday, 30 September 2021 at 03:21:51 UTC, jfondren wrote:
On Thursday, 30 September 2021 at 03:13:28 UTC, jfondren wrote:
As provided, loadSymbol without the "static if":
965K libhipengine_api.a
with `mixin(loadSymbol("name"))` instead of a template:
749K libhipengine_api.a
The differ
On Thursday, 30 September 2021 at 03:13:28 UTC, jfondren wrote:
As provided, loadSymbol without the "static if":
965K libhipengine_api.a
with `mixin(loadSymbol("name"))` instead of a template:
749K libhipengine_api.a
The difference goes down to 66K vs. 60K with `dub -brelease
--compiler=gdc
On Thursday, 30 September 2021 at 02:31:50 UTC, Hipreme wrote:
https://github.com/MrcSnm/HipremeEngine/tree/hotload/api
You may try messing at the module api.graphics.g2d.renderer2d
There is a function called initG2D
Try changing it from loadSymbols to each one loadSymbol.
You can just dub at
On Thursday, 30 September 2021 at 02:22:35 UTC, jfondren wrote:
On Thursday, 30 September 2021 at 01:44:57 UTC, jfondren wrote:
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a
symbol, it loads a dll for its type + its name:
On Thursday, 30 September 2021 at 01:44:57 UTC, jfondren wrote:
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
st
On Thursday, 30 September 2021 at 02:09:50 UTC, Hipreme wrote:
I could reduce by almost 100kb of code by instead of using the
former option, I use:
yes this is what id o you can list the Ts in an interface too.
see my simpledisplay.d `interface GL` for example
I do still don't think that th
On Thursday, 30 September 2021 at 02:02:19 UTC, Hipreme wrote:
Instead of writing
myFunction = cast(typeof(myFunction))_loadSymbol(_dll,
"myFunction");
I could write
loadSymbol!myFunction;
But if no other way is found of doing that, I will do the
massive rewriting.
---
void function() x
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSy
On Thursday, 30 September 2021 at 02:02:19 UTC, Hipreme wrote:
On Thursday, 30 September 2021 at 01:56:42 UTC, Basile B. wrote:
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a
symbol, it loads a dll for its type + its name:
On Thursday, 30 September 2021 at 01:56:42 UTC, Basile B. wrote:
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
s
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSy
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSy
I have a template function that all it does is given a symbol, it
loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSymbol(_dll, (s.stringof~"\0").ptr);
else
On Friday, 30 July 2021 at 10:20:36 UTC, Stefan Koch wrote:
On Friday, 30 July 2021 at 09:30:13 UTC, Mike Parker wrote:
On Friday, 30 July 2021 at 08:38:24 UTC, dangbinghoo wrote:
but, where's these switch option documented? it seems it not
appears in dmd --help or man dmd, or online documen
On Friday, 30 July 2021 at 09:30:13 UTC, Mike Parker wrote:
On Friday, 30 July 2021 at 08:38:24 UTC, dangbinghoo wrote:
but, where's these switch option documented? it seems it not
appears in dmd --help or man dmd, or online document
https://dlang.org/dmd-linux.html
That's what he meant
On Friday, 30 July 2021 at 09:30:13 UTC, Mike Parker wrote:
On Friday, 30 July 2021 at 08:38:24 UTC, dangbinghoo wrote:
but, where's these switch option documented? it seems it not
appears in dmd --help or man dmd, or online document
https://dlang.org/dmd-linux.html
That's what he meant
On Friday, 30 July 2021 at 08:38:24 UTC, dangbinghoo wrote:
but, where's these switch option documented? it seems it not
appears in dmd --help or man dmd, or online document
https://dlang.org/dmd-linux.html
That's what he meant by "hidden" switch. I don't know why it
isn't documented, b
On Friday, 30 July 2021 at 06:46:18 UTC, WebFreak001 wrote:
On Friday, 30 July 2021 at 06:00:41 UTC, dangbinghoo wrote:
Not sure if this is exactly what you want but there is a hidden
switch in dmd called `-vcg-ast` that prints out all the
templates instantiated.
but, where's these switch
On Friday, 30 July 2021 at 06:46:18 UTC, WebFreak001 wrote:
On Friday, 30 July 2021 at 06:00:41 UTC, dangbinghoo wrote:
Not sure if this is exactly what you want but there is a hidden
switch in dmd called `-vcg-ast` that prints out all the
templates instantiated.
On run.dlang.io you can use
On Friday, 30 July 2021 at 06:00:41 UTC, dangbinghoo wrote:
hi, is there any D compiler option or other method to view the
final template instantiation but not compiled (in asm or
binary) code?
if there's a way, it might be very usefull for newbies like me
to learn and understand th
hi, is there any D compiler option or other method to view the
final template instantiation but not compiled (in asm or binary)
code?
if there's a way, it might be very usefull for newbies like me to
learn and understand the the Meta programming of dlang.
thanks!
dbh
On Monday, 27 April 2020 at 17:40:06 UTC, Steven Schveighoffer
wrote:
[snip]
Thanks for that. Very detailed.
In terms of a use case, we just added a center function to mir
[1]. It can take an alias to a function. I wanted to add a check
that the arity of the function was 1, but it turned out
On Mon, Apr 27, 2020 at 05:19:35PM +, jmh530 via Digitalmars-d-learn wrote:
> When using a template with multiple functions within it, is it
> possible to access the underlying functions directly?
Yes, but only if the template is not eponymous.
> Not sure I am missing anything, but what work
On 4/27/20 1:19 PM, jmh530 wrote:
When using a template with multiple functions within it, is it possible
to access the underlying functions directly? Not sure I am missing
anything, but what works when the functions are named differently from
the headline template doesn't work when the functio
When using a template with multiple functions within it, is it
possible to access the underlying functions directly? Not sure I
am missing anything, but what works when the functions are named
differently from the headline template doesn't work when the
functions are named the same.
import st
On Friday, 10 January 2020 at 18:31:59 UTC, ag0aep6g wrote:
import m1 = foo.baz;
import m2 = foo;
alias p = __traits(parent, m1);
pragma(msg, m1.stringof); /* "module baz", ok */
pragma(msg, m2.stringof); /* "module foo", ok */
pragma(msg, p.stringof); /* "package foo", ok */
enum e(alias
On 10.01.20 18:27, berni44 wrote:
This clearly shows, that packageName is only instatiated once at top
level although mod0 and mod1 are two different things (at least their
stringof produces different results) and therefore should be
instantiated twice.
Now I don't know if this is a bug in DM
I'm trying to understand issue 17441 [1]. I reduced it (including
Phobos) to the following (and added some message to point out the
problem):
test.d:
---
alias parentOf(alias sym) = __traits(parent, sym);
template packageName(alias T)
{
pragma(msg, "IN: ", T.stringof);
static if (__tra
On Thursday, 14 November 2019 at 09:30:23 UTC, user9876 wrote:
A good thing is that in many cases the template instance
parameters can be deduced from the arguments used:
---
import std;
void main()
{
assert(max(0,1) == 1);
// same as assert(max!(int,int)(0,1) == 1);
}
---
This featur
On Wednesday, 13 November 2019 at 14:01:13 UTC, BoQsc wrote:
I don't like to see exclamation marks in my code in as weird
syntax as these ones:
to!ushort(args[1])
s.formattedRead!"%s!%s:%s"(a, b, c);
I'm not sure why, but template instantiation syntax is
prevalent
On Wednesday, 13 November 2019 at 14:23:40 UTC, mipri wrote:
3. it's very clear what's a compile-time vs. a runtime
parameter to the template.
At least, if one understands the difference. I remember that I
was not aware of this, when I started learning D and was a lot
confused by the use of t
On 11/13/19 9:01 AM, BoQsc wrote:
I don't like to see exclamation marks in my code in as weird syntax as
these ones:
to!ushort(args[1])
s.formattedRead!"%s!%s:%s"(a, b, c);
I'm not sure why, but template instantiation syntax is prevalent in the
documentation examples of
On Wednesday, 13 November 2019 at 14:59:57 UTC, Dukc wrote:
4: Templates. Same code size bloat as with options 1 and 3,
Meant binary size bloat
On Wednesday, 13 November 2019 at 14:01:13 UTC, BoQsc wrote:
I don't like to see exclamation marks in my code in as weird
syntax as these ones:
to!ushort(args[1])
s.formattedRead!"%s!%s:%s"(a, b, c);
No pressure to use templates. D is designed to be multi-paradigm,
and in many was combines th
On Wednesday, November 13, 2019 7:01:13 AM MST BoQsc via Digitalmars-d-learn
wrote:
> I don't like to see exclamation marks in my code in as weird
>
> syntax as these ones:
> > to!ushort(args[1])
> > s.formattedRead!"%s!%s:%s"(a, b, c);
>
> I'm not
ly*
doing some work at compile-time here, instead of at runtime like
other languages force me to") than an alert ("something weird is
happening!") though.
3. it's very clear what's a compile-time vs. a runtime parameter
to
the template.
I'm not sure why, but template inst
I don't like to see exclamation marks in my code in as weird
syntax as these ones:
to!ushort(args[1])
s.formattedRead!"%s!%s:%s"(a, b, c);
I'm not sure why, but template instantiation syntax is prevalent
in the documentation examples of d lang libraries. It almost
se
On Wednesday, September 12, 2018 9:42:19 PM MDT James Blachly via
Digitalmars-d-learn wrote:
> Neia is right that I tried to cast as in the second case ( but
> without UFCS -- reserve( cast(int[]), N); ). As an aside, what
> is going on behind the scenes with the compiler when casting away
> a pr
Great -- Thank you both.
I previously found Unqual, but it looks like that needs template
support so wasn't feasible, hence my question.
Neia is right that I tried to cast as in the second case ( but
without UFCS -- reserve( cast(int[]), N); ). As an aside, what
is going on behind the scene
On Wednesday, September 12, 2018 5:41:16 PM MDT James Blachly via
Digitalmars-d-learn wrote:
> When I add the "shared" attribute to an array, I am no longer
> able to call reserve because the template won't instantiate:
>
> Error: template object.reserve cannot deduce function from
> argument type
On Wednesday, 12 September 2018 at 23:41:16 UTC, James Blachly
wrote:
When I add the "shared" attribute to an array, I am no longer
able to call reserve because the template won't instantiate:
Error: template object.reserve cannot deduce function from
argument types !()(shared(int[]), int), ca
When I add the "shared" attribute to an array, I am no longer
able to call reserve because the template won't instantiate:
Error: template object.reserve cannot deduce function from
argument types !()(shared(int[]), int), candidates are:
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d
On Wednesday, June 27, 2018 22:59:03 Nathan S. via Digitalmars-d-learn
wrote:
> On Wednesday, 27 June 2018 at 22:39:26 UTC, Jonathan M Davis
>
> wrote:
> > You could explicitly instantiate the function template and then
> > take its address.
>
> Explicitly instantiating the template can result in
On 6/27/18 6:34 PM, Nathan S. wrote:
Let's say there's a function template `doImpl` and `doImpl(x)` compiles
thanks to IFTI. Is there any way to get the address of the function that
would be called in `doImpl(x)`?
It's a good question!
You may be able to use TemplateOf, TemplateArgsOf, and In
On Wednesday, 27 June 2018 at 22:39:26 UTC, Jonathan M Davis
wrote:
You could explicitly instantiate the function template and then
take its address.
Explicitly instantiating the template can result in a function
that may be behaviorally identical but have a different address.
https://run.dl
On Wednesday, June 27, 2018 22:34:46 Nathan S. via Digitalmars-d-learn
wrote:
> Let's say there's a function template `doImpl` and `doImpl(x)`
> compiles thanks to IFTI. Is there any way to get the address of
> the function that would be called in `doImpl(x)`?
You could explicitly instantiate the
Let's say there's a function template `doImpl` and `doImpl(x)`
compiles thanks to IFTI. Is there any way to get the address of
the function that would be called in `doImpl(x)`?
On 5/17/18 7:33 PM, Bastiaan Veelo wrote:
On Thursday, 17 May 2018 at 23:18:32 UTC, Basile B. wrote:
On Thursday, 17 May 2018 at 22:07:46 UTC, Bastiaan Veelo wrote:
Hi!
The code in [1] compiles and runs flawlessly on Windows, but not on
Linux (neither run.dlang nor Travis docker image). Any i
On Thursday, 17 May 2018 at 23:18:32 UTC, Basile B. wrote:
On Thursday, 17 May 2018 at 22:07:46 UTC, Bastiaan Veelo wrote:
Hi!
The code in [1] compiles and runs flawlessly on Windows, but
not on Linux (neither run.dlang nor Travis docker image). Any
idea what can be done?
Hello. Yes, add `i
On Thursday, 17 May 2018 at 22:07:46 UTC, Bastiaan Veelo wrote:
Hi!
The code in [1] compiles and runs flawlessly on Windows, but
not on Linux (neither run.dlang nor Travis docker image). Any
idea what can be done?
Hello. Yes, add `import core.stdc.stdarg;` in your module and it
works.
I do
Hi!
The code in [1] compiles and runs flawlessly on Windows, but not
on Linux (neither run.dlang nor Travis docker image). Any idea
what can be done?
errors:
Error: undefined identifier __va_list_tag
onlineapp.d(282): Error: template instance
`onlineapp.SetFactory!byte` error instantiating
On Friday, 9 February 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:
[1] https://run.dlang.io/is/dyElXg
There's missing quotes in there:
Line 14:
code ~= "push(call!"~piece~"(pop(), pop()));\n";
Should be:
code ~= "push(call!\""~piec
On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:
writeln(parse(code)); // to aid with debugging
writeln(convertToD(parse(code))); // debugging aid
..to..
writeln(parse(code)[]); // to aid with debugging
writeln(convertToD(parse(
On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:
[1] https://run.dlang.io/is/dyElXg
There's missing quotes in there:
Line 14:
code ~= "push(call!"~piece~"(pop(), pop()));\n";
Should be:
code ~= "push(call!\""~piece~"\"(pop(), pop()));\n";
That might have been an error in the o
Hi,
Trying to improve my CT-fu, I looked at a DSL example (chapter 9)
in Adam's D-Cookbook. Although I am sure Adam's original examples
would have worked, there were some errors in the example code in
the book.
The example also contains some code to allow you to test the
functions at RT, wh
On 6/12/17 11:31 AM, Arafel wrote:
As you can see, the only change is the type the function returns, but I
don't see how it should make any difference.
Also, changing from "enum" to "static immutable", or even removing the
"enum" and directly embedding the function literal doesn't seem to make
Well, I had kind of found a workaround (changing the return type to
return the element and not the index) which I didn't like too much (what
if there are duplicates?).
Now that I've found a "proper" workaround well, I'm still interested
in knowing the reason, if possible, or if it's a bug.
Arafel wrote:
I actually found a workaround for the original issue:
yeah, sorry for not proposing a workaround: i thought that you already did
it, and now you're just interested why the original code doesn't work. ;-)
i think that this is a bug (or, rather, unimplemented feature).
On Monday, 12 June 2017 at 19:23:10 UTC, ketmar wrote:
p.s.: while i understand the technical reason for second error
message, it is still random and confusing.
I think the reason for the typeof problem is that it works with
expressions, not with types (so, typeof (int) is also not valid),
an
p.s.: while i understand the technical reason for second error message, it
is still random and confusing.
more funny compiler messages:
alias xx = size_t function (int[]);
struct S1(T, typeof(xx) X) {}
void main() {
S1!(int, defaultChooser!int) s;
}
Error: type uint function(int[]) is not an expression
but:
struct S2(T, typeof(defaultChooser!T) cho
On 06/12/2017 05:31 PM, Arafel wrote:
Hi,
I've found a strange problem, and I'm not sure if it's a bug. To give a
bit of background, I'm implementing a multi-threaded producer-consumer
where the next work item to be picked depends not only on the "waiting
queue", but also on what else is bein
Hi,
I've found a strange problem, and I'm not sure if it's a bug. To give a
bit of background, I'm implementing a multi-threaded producer-consumer
where the next work item to be picked depends not only on the "waiting
queue", but also on what else is being run (and potentially where) at
the s
On 03/13/2017 11:58 PM, Stefan Koch wrote:
On Monday, 13 March 2017 at 22:05:24 UTC, Jack Applegame wrote:
Is this a bug?
No it's not
struct C
{
B!C;
}
is an error.
Howto compute C ? <--\
let's check the members; |
The member needs a template. |
Howto compute the template
On 03/14/2017 12:02 AM, Stefan Koch wrote:
On Monday, 13 March 2017 at 22:59:36 UTC, ag0aep6g wrote:
[...]
struct A(T) {
void m() {
char[T.sizeof] data;
}
}
/* ... rest as above ... */
I don't see how the destructor makes a difference. Soo, bug?
Try to use m.
Work
On Monday, 13 March 2017 at 22:59:36 UTC, ag0aep6g wrote:
On 03/13/2017 03:26 PM, Jack Applegame wrote:
I'm pretty sure that this code should compile
(https://dpaste.dzfl.pl/cf1e1ee6ef4b):
struct A(T) {
~this() {
char[T.sizeof] data;
}
}
struct B(T) {
A!T foo;
}
struct C {
On 03/13/2017 03:26 PM, Jack Applegame wrote:
I'm pretty sure that this code should compile
(https://dpaste.dzfl.pl/cf1e1ee6ef4b):
struct A(T) {
~this() {
char[T.sizeof] data;
}
}
struct B(T) {
A!T foo;
}
struct C {
B!C bar;
}
void main() {
C c;
}
But it doesn't:
On Monday, 13 March 2017 at 22:05:24 UTC, Jack Applegame wrote:
Is this a bug?
No it's not
struct C
{
B!C;
}
is an error.
Howto compute C ? <--\
let's check the members; |
The member needs a template. |
Howto compute the template ? |
let's compute the parameters. |
What
Is this a bug?
I'm pretty sure that this code should compile
(https://dpaste.dzfl.pl/cf1e1ee6ef4b):
struct A(T) {
~this() {
char[T.sizeof] data;
}
}
struct B(T) {
A!T foo;
}
struct C {
B!C bar;
}
void main() {
C c;
}
But it doesn't:
/d300/f416.d(3): Error: struct f416.C no size
On Monday, 27 June 2016 at 17:17:19 UTC, John wrote:
import std.traits;
__traits(identifier, TemplateOf!(S!int));
Scratch that, this is what you want:
import std.traits;
static assert(__traits(isSame, TemplateOf!(S!int), S));
I believe this is what
import std.traits : isInstanceOf;
is
On Monday, 27 June 2016 at 17:14:23 UTC, John wrote:
On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(
On 06/27/2016 09:54 AM, Lodovico Giaretta wrote:
On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(S!in
On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(S!int) == S));
Is this already in Phobos somewhere?
On Monday, 27 June 2016 at 16:40:09 UTC, Nordlöw wrote:
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(S!int) == S));
Is this already in Phobos somewhere?
If I have a template parameter
E = S!int
where
struct S(T) { S x; }
how can I extract the template name part `S` from E`?
Something like:
static assert(is(templateName!(S!int) == S));
Is this already in Phobos somewhere?
On Thursday, 19 May 2016 at 20:14:48 UTC, vit wrote:
Is this a bug?
Yes. I've filed a report:
https://issues.dlang.org/show_bug.cgi?id=16050
///Hello, i'm trying to implement d compiler and i've problems
with some template corner cases.
class Type{}
class Foo(T : const T){
alias X = T;
}
alias Bar(T : Foo!Ts, Ts...) = Ts[0];
pragma(msg, "Foo1: ", Foo!(immutable Type).X);//Foo1: Type
pragma(msg, "Foo2: ", F
It looks like the bug has already been reported. There are a few
associated with __traits(compiles), but this one seems most
relevant:
https://issues.dlang.org/show_bug.cgi?id=3448
It also suggests that this is relevant:
https://issues.dlang.org/show_bug.cgi?id=965
On Thursday, 7 April 2016 at 21:36:37 UTC, Alex Parrill wrote:
On Thursday, 7 April 2016 at 20:31:12 UTC, jmh530 wrote:
I've been playing around with __traits and I find myself
confused on one aspect. In the code below, I was testing
whether some templates would compile given types. For the mos
On Thursday, 7 April 2016 at 20:31:12 UTC, jmh530 wrote:
I've been playing around with __traits and I find myself
confused on one aspect. In the code below, I was testing
whether some templates would compile given types. For the most
part it works as I would expect.
I think I get why the thir
I've been playing around with __traits and I find myself confused
on one aspect. In the code below, I was testing whether some
templates would compile given types. For the most part it works
as I would expect.
I think I get why the third one works with foo!(int). My guess is
that it assumed t
On Saturday, 30 January 2016 at 00:16:21 UTC, Ali Çehreli wrote:
> https://issues.dlang.org/show_bug.cgi?id=15623
As I noted on the bug report, they are work when moved from
module scope to inside a function (e.g. main()). At least
there's that workaround...
Ali
Thanks a lot! Now I can con
On Friday, 29 January 2016 at 23:44:56 UTC, Basile B. wrote:
Haven't you seen my answer about constraint ?
If you put a constraint on your function template then invalid
instantiations are rejected. I mean... this language feature is
not just ornamental...
What do you think constraints are u
On 01/29/2016 09:01 AM, Adrian Matoga wrote:
> Oh, there's more:
> // this should fail:
> static assert(is(CallsFoo!NoFoo));
> // this should fail too:
> static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init;
> }(;
> // and this:
> static assert(__traits(compiles, { alias Baz
^
A constraint should not be necessary here. Constraints are useful when
you have multiple templates that may match (without specializations), or
you want to affect the way the compiler reports errors.
Iff a template instantiation T compiles, then is(T) should evaluate to
true. At least, that
1 - 100 of 166 matches
Mail list logo
