On 05/02/2012 04:14 AM, Mehrdad wrote:
Yes, that non-global issue was the exact issue I was referring to. It
drives me nuts whenever I try to give in and use templates.
Regarding your fix:
Is it *really* intended that user should say
arr.filter((typeof(some_random_expression) x) = x y);
On 05/02/12 04:11, Mehrdad wrote:
More problems... similar, but this time related to templates.
struct Filter(R) { this(R) { } }
template filter(R) { alias Filter!(R).__ctor filter; }
void main() { filter([1, 2, 3]); }
Error: template linq.filter(R) is not a function template
Why?
On Tue, 01 May 2012 22:11:18 -0400, Mehrdad wfunct...@hotmail.com wrote:
More problems... similar, but this time related to templates.
struct Filter(R) { this(R) { } }
template filter(R) { alias Filter!(R).__ctor filter; }
void main() { filter([1, 2, 3]); }
Error: template
On 05/01/2012 04:02 AM, Mehrdad wrote:
Wha..?!
I can't believe delegates work so poorly in D...
It is not the delegates, it is the type deduction algorithm for implicit
function template instantiation. The issue is that the parameters do not
cross-talk, which means R is not known during
I guess the problem is with type deduction, but the trouble is that half the
reason why type deduction is useful is in the case of lambdas. They become
effectively useless if you have to type out their entire signature, since
you could then just make them a separate function (or just use a
On 01/05/2012 02:00, Mehrdad wrote:
Some ICE for y'all.
void filter(R)(scope bool delegate(ref BAD!R) func) { }
void main() { filter(r = r); }
Is this in bugzilla? It can't get fixed if no one knows about it! (Make
sure to give it the ice keyword once you've submitted so it gets bumped
to
On 05/01/2012 01:20 PM, Mehrdad wrote:
I guess the problem is with type deduction, but the trouble is that half
the reason why type deduction is useful is in the case of lambdas. They
become effectively useless if you have to type out their entire
signature, since you could then just make them a
Yeah I just posted it yesterday.
http://d.puremagic.com/issues/show_bug.cgi?id=8009
Robert Clipsham wrote in message news:jnoi6g$1f79$1...@digitalmars.com...
On 01/05/2012 02:00, Mehrdad wrote:
Some ICE for y'all.
void filter(R)(scope bool delegate(ref BAD!R) func) { }
void main() {
More problems... similar, but this time related to templates.
struct Filter(R) { this(R) { } }
template filter(R) { alias Filter!(R).__ctor filter; }
void main() { filter([1, 2, 3]); }
Error: template linq.filter(R) is not a function template
Why?
Yes, that non-global issue was the exact issue I was referring to. It drives
me nuts whenever I try to give in and use templates.
Regarding your fix:
Is it *really* intended that user should say
arr.filter((typeof(some_random_expression) x) = x y);
instead of
arr.filter(x = x y);
?
I
Some ICE for y'all.
void filter(R)(scope bool delegate(ref BAD!R) func) { }
void main() { filter(r = r); }
Also, what exactly is wrong with this code?
private import std.range;
void filter(R)(R, bool delegate(ElementType!R)) { }
void main() { [1, 2, 3].filter(delegate bool(x) { return x 3; }); }
On 05/01/2012 03:09 AM, Mehrdad wrote:
Also, what exactly is wrong with this code?
private import std.range;
void filter(R)(R, bool delegate(ElementType!R)) { }
void main() { [1, 2, 3].filter(delegate bool(x) { return x 3; }); }
The current type deduction strategy for IFTI is (imho) too
On 05/01/2012 03:46 AM, Mehrdad wrote:
Is it just weak, or is it outright wrong?
Unfortunately it is by design that it does not work afaik.
It's telling me R isn't a valid identifier...
That one is a diagnostics bug.
Is it just weak, or is it outright wrong?
It's telling me R isn't a valid identifier...
Timon Gehr wrote in message news:jnnefl$2j69$1...@digitalmars.com...
On 05/01/2012 03:09 AM, Mehrdad wrote:
Also, what exactly is wrong with this code?
private import std.range;
void filter(R)(R, bool
Wha..?!
I can't believe delegates work so poorly in D... they're practically
unusable unless you're passing them as template parameters (which brings on
its own set of bugs)...
Seems like every time I try to escape a bug somehow, another one pops up :(
Timon Gehr wrote in message
On Saturday, 28 April 2012 at 09:36:55 UTC, Timon Gehr wrote:
On 04/28/2012 08:03 AM, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
D templates are
On Sunday, 29 April 2012 at 06:22:34 UTC, James Miller wrote:
D templates are analysed eagerly upon instantiation, whereas
C++ templates are analysed lazily. This is not a bug, it is a
feature.
Furthermore, eager analysis is necessary for other D features
like CTFE and compile-time
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
Try thinking about your code before mouthing off here.
Not trying to to be rude, but did you think about *your* reason
On Saturday, 28 April 2012 at 06:03:54 UTC, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
dmd is not smart enough to avoid recursion by treating f as
On 04/28/2012 08:03 AM, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
D templates are analysed eagerly upon instantiation, whereas C++
templates
On 04/28/2012 09:46 AM, Max Samukha wrote:
On Saturday, 28 April 2012 at 06:03:54 UTC, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
dmd is not smart
On Saturday, 28 April 2012 at 09:36:55 UTC, Timon Gehr wrote:
On 04/28/2012 08:03 AM, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
D templates are
On Saturday, 28 April 2012 at 09:40:49 UTC, Timon Gehr wrote:
On 04/28/2012 09:46 AM, Max Samukha wrote:
On Saturday, 28 April 2012 at 06:03:54 UTC, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
On 04/28/2012 12:05 PM, Max Samukha wrote:
On Saturday, 28 April 2012 at 09:40:49 UTC, Timon Gehr wrote:
On 04/28/2012 09:46 AM, Max Samukha wrote:
On Saturday, 28 April 2012 at 06:03:54 UTC, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() {
Okay, final exams are coming up again, and so are my bugs (I have no idea
what the correlation is, don't ask...)
I guess I should post this on bugzilla, but oh well... I continued the
thread instead.
Try compiling this (I did this on Windows, DMD 2.059):
void main() { Foo!(int[])([[1], [2]]);
Oh sorry, here's the previous thread... somehow it got detached because of
the subject line change:
http://lists.puremagic.com/pipermail/digitalmars-d/2011-December/117172.html
On Saturday, 28 April 2012 at 04:45:59 UTC, Mehrdad wrote:
Okay, final exams are coming up again, and so are my bugs (I
have no idea what the correlation is, don't ask...)
I guess I should post this on bugzilla, but oh well... I
continued the thread instead.
Try compiling this (I did this on
Adam D. Ruppe:
I do a lot. The way I do it is the arguments are made
available to the format, but it doesn't always need them
at runtime.
string f = showNames ? %1$s\t%2$d : %2$d;
writefln(f, name, number);
Though I don't literally use writefln for most
my code the same idea applies.
On 11/02/2011 09:00 PM, Adam D. Ruppe wrote:
bearophile:
But how many times do you want to ignore some of the
arguments listed?
I do a lot. The way I do it is the arguments are made
available to the format, but it doesn't always need them
at runtime.
string f = showNames ? %1$s\t%2$d : %2$d;
bearophile wrote:
Currently this is not caught by D, it prints 12:
import std.stdio;
void main() {
writefln(%d%d, 1, 2, 3);
}
That's not really an error. You might change out the format
string at runtime based on user preferences, perhaps for
internationalization, or other reasons.
Personally I like using this for a sort of on/off switch:
bool val;
// ..
val ^= 1;
Maybe that's just stupid but I'm kind of used to it, lol. :p
Adam D. Ruppe:
bearophile wrote:
Currently this is not caught by D, it prints 12:
import std.stdio;
void main() {
writefln(%d%d, 1, 2, 3);
}
That's not really an error. You might change out the format
string at runtime based on user preferences, perhaps for
Andrej Mitrovic:
Personally I like using this for a sort of on/off switch:
bool val;
// ..
val ^= 1;
Maybe that's just stupid but I'm kind of used to it, lol. :p
I use this, I think it's more explicit (but you have to state the variable name
two times):
val = !val;
Bye,
bearophile
bearophile:
But how many times do you want to ignore some of the
arguments listed?
I do a lot. The way I do it is the arguments are made
available to the format, but it doesn't always need them
at runtime.
string f = showNames ? %1$s\t%2$d : %2$d;
writefln(f, name, number);
Though I don't
http://d.puremagic.com/issues/show_bug.cgi?id=3293
--- Comment #3 from Don clugd...@yahoo.com.au 2009-09-08 08:51:49 PDT ---
Here's a reduced test case for the second bug, which is ICE(expression.c).
Something to do with recursive alias parameters causing data corruption.
Only happens if there
http://d.puremagic.com/issues/show_bug.cgi?id=3293
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
---
http://d.puremagic.com/issues/show_bug.cgi?id=3293
--- Comment #2 from Don clugd...@yahoo.com.au 2009-09-07 08:29:30 PDT ---
Bug 1 is now its own issue, bug 3304.
Bug 3 is now its own issue, bug 3305.
They are completely unrelated to one another.
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=3293
Summary: A few more bugs with template mixins with identifiers
Product: D
Version: 2.031
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-valid-code, rejects
39 matches
Mail list logo
