On Tuesday, 26 March 2013 at 06:15:54 UTC, cal wrote:
static if (is(S!(int, 5) _ : S!(U), U...)) // line B, fail
pragma(msg, U.stringof); // tuple(int, 5);
oops the '// line B, fail' should not be there
On Tuesday, 26 March 2013 at 06:03:55 UTC, cal wrote:
I.e., why I can't match on some generic second parameter - what
if the second parameter was an int:
struct S(A, int B) {}
static assert(is(S!(int, 5627) _ == S!(U, ??), U, ??));
how to match that in the isExpression?
cheers,
cal
However
On Tuesday, 26 March 2013 at 05:28:22 UTC, Ali Çehreli wrote:
I am not sure that I understand but usually the test is done in
a context like foo() below:
struct S(A, bool B) {}
void foo(T)()
{
static assert(is(T == S!(U, false), U));
}
void main()
{
foo!(S!(int, false))();
}
Ali
Ma
why doesn't this compile?
import std.traits;
import std.algorithm;
void main(){
auto a=sort([1]);
enum t=fullyQualifiedName!(typeof(a));
pragma(msg,t);
}
CT error: std/traits.d(298): Error: forward reference of variable parentPrefix
Timothee Cour
On Tue, 26 Mar 2013 01:28:03 -0400, Sergei Nosov
wrote:
Thank you, guys!
You made the matters clear to me!
It would be an interesting enhancement over C++.
Although, Steven, I didn't quite understand what you're suggesting to
use in case of "templated-struct-templated-constructor"
Expl
On 03/25/2013 04:57 PM, cal wrote:
Trying to figure out how to pattern-match struct S below with an
isExpression:
struct S(A, bool B) {}
static assert ( !is(S!(int, false) _ == S!(U, bool), U) );
static assert ( !is(S!(int, false) _ == S!(U, V), U, V) );
static assert ( !is(S!(int, false) _ ==
Thank you, guys!
You made the matters clear to me!
It would be an interesting enhancement over C++.
Although, Steven, I didn't quite understand what you're
suggesting to use in case of
"templated-struct-templated-constructor"
Explicitly specifying struct parameters is ok. Deducing
construc
You make me curious about this new attribute. Maybe I could then
help to implement this along with its task.
I do not think anyone else has the time to do it.
I hope that you will find the link.
On Tuesday, March 26, 2013 00:52:56 Namespace wrote:
> Forgot to ask:
> Wouldn't it be better to publish this decision?
> Many still believe the nonsense (like me) that 'auto ref' is
> still the solution.
An official decision would mean that Walter had been involved in it, and that
hasn't happene
Forgot to ask:
Wouldn't it be better to publish this decision?
Many still believe the nonsense (like me) that 'auto ref' is
still the solution.
On Mon, 25 Mar 2013 17:13:58 -0400, Ali Çehreli wrote:
On 03/25/2013 12:40 PM, Steven Schveighoffer wrote:
> On Mon, 25 Mar 2013 11:31:17 -0400, Ali Çehreli
wrote:
>
>> This design allows templated constructors:
>>
>> struct S // <-- not a template
>> {
>> this(T)(T t) // <-- templat
I appreciate your efforts and look forward to the link. :)
But I never heard anything about that. How long has it been since
that was suggested?
But that's honestly sad to hear. I thought I would contribute to
the solution of this problem. Then we'll have to wait and
continue to hope.
You will likely get better performance if you use:
a ~= int.init;
instead of:
a.length++;
So that's a relief, a dynamic array in D actually *is* an
efficient queue implementation out of the box, I just did it
improperly in the example. Thank you for the correction. With
that, the number
On Mar 22, 2013, at 2:58 AM, Benjamin Thaut wrote:
> So I want to install my own assertHandler. The problem is, that even if I
> call "setAssetHandler" in a shared module constructor, and that module does
> not import any other modules, it is still not initialized first. Is there a
> way to se
On Mar 23, 2013, at 5:22 AM, Jacob Carlborg wrote:
> I'm wondering because I see that std.json uses isControl, isDigit and
> isHexDigit from std.ascii and not std.uni. This also causes a problem with a
> pull request I recently made for std.net.isemail. In one of its unit tests
> the DEL chara
On Monday, March 25, 2013 23:35:06 Namespace wrote:
> > Because the number of instantiations of the template could grow
> > exponentially
> > as the number of auto ref parameters grows. Being able to use
> > the trick with
> > the temporary with templated functions could really help reduce
> > temp
Is there a way to get the names of the fields in a named tuple? It looks
like the names are actually aliases.
Thanks,
JC
Because the number of instantiations of the template could grow
exponentially
as the number of auto ref parameters grows. Being able to use
the trick with
the temporary with templated functions could really help reduce
template bloat
when the current meaning of auto ref is not necessary, but tha
On Monday, March 25, 2013 20:43:29 Namespace wrote:
> > Basically, someone needs to implement it and then talk Walter
> > into accepting
> > it. That'll be easier for someone like Kenji, who's already a
> > major
> > contributor, but in theory, anyone can do it. It's just that
> > there's a high
>
On 03/25/2013 12:40 PM, Steven Schveighoffer wrote:
> On Mon, 25 Mar 2013 11:31:17 -0400, Ali Çehreli
wrote:
>
>> This design allows templated constructors:
>>
>> struct S // <-- not a template
>> {
>> this(T)(T t) // <-- template
>> {
>> // ...
>> }
>>
>> // ...
>> }
>>
>> The same in C++...
>
Basically, someone needs to implement it and then talk Walter
into accepting
it. That'll be easier for someone like Kenji, who's already a
major
contributor, but in theory, anyone can do it. It's just that
there's a high
risk that the pull request would languish for a while. And it
would probab
On Mon, 25 Mar 2013 11:31:17 -0400, Ali Çehreli wrote:
This design allows templated constructors:
struct S // <-- not a template
{
this(T)(T t) // <-- template
{
// ...
}
// ...
}
The same in C++...
Templated constructors would not be disallowed if you
On Mon, 25 Mar 2013 11:11:40 -0400, Sergei Nosov
wrote:
On Monday, 25 March 2013 at 14:12:17 UTC, bearophile wrote:
Sergei Nosov:
Everything's fine if I specify parameters explicitly:
test!int hello = test!int(cptr);
Some persons have proposed alternative designs, but D is working as
c
Where or to whom should I report a bug in the thrift D bindings?
In recent ubuntu, the maintainers inexplicably changed the linker
(ld) defaults to --as-needed, which breaks the 'make check' for
Thrifts D binding, presumably because they are using some kind of
'indirect' linking.
reproductio
On 03/25/2013 08:11 AM, Sergei Nosov wrote:
> On Monday, 25 March 2013 at 14:12:17 UTC, bearophile wrote:
>> Sergei Nosov:
>>
>>> Everything's fine if I specify parameters explicitly:
>>>
>>> test!int hello = test!int(cptr);
>>>
>>
>> Some persons have proposed alternative designs, but D is work
If you happened to get that accidental blank send, sorry, I tried to
cancel it.
On Sat, 23 Mar 2013 19:45:21 -0400, Ivan Kazmenko wrote:
On Saturday, 23 March 2013 at 19:33:06 UTC, Jonathan M Davis wrote:
You might want to check out this article where someone ran into similar
issues:
htt
On Monday, 25 March 2013 at 14:12:17 UTC, bearophile wrote:
Sergei Nosov:
Everything's fine if I specify parameters explicitly:
test!int hello = test!int(cptr);
Some persons have proposed alternative designs, but D is
working as currently designed here... Unlike template
functions, templa
Sergei Nosov:
Everything's fine if I specify parameters explicitly:
test!int hello = test!int(cptr);
Some persons have proposed alternative designs, but D is working
as currently designed here... Unlike template functions,
templated structs don't infer the type.
Bye,
bearophile
Hi!
This code doesn't compile with dmd v2.062 on Linux_x86_64
struct test(T)
{
T *data_;
this(T *data) {
data_ = data;
}
}
void main()
{
int *cptr = null;
test!int hello = test(cptr);
}
Error:
dmd test.d
test.d(12): Error: struct test.test does not match any funct
29 matches
Mail list logo
