On 2011-01-31 19:46:53 +0100, Simen kjaeraas said:
Magnus Lie Hetland mag...@hetland.org wrote:
Hm. Using code quite similar to you, supplying a lambda in the second
aliasing, I get this error:
something.d(93): Error: template instance cannot use local
'__dgliteral2(__T3)' as parameter to
On 2011-02-01 10:11:53 +0100, Magnus Lie Hetland said:
On 2011-01-31 22:21:40 +0100, bearophile said:
Magnus Lie Hetland:
[snip]
I'm accustomed to is the ability to
assign to multiple variables, such as
arg, val = minArg(...)
(Yeah, I'm a Python guy... ;)
I will eventually add a
Magnus Lie Hetland:
Saw your post on digitalmars.D now, about the currying of templates
(i.e., the main topic here). I guess perhaps that was what you were
talking about?
Tuple unpacking syntax and template currying are two different things.
Bye,
bearophile
On 2011-02-01 10:49:23 +0100, bearophile said:
Magnus Lie Hetland:
Saw your post on digitalmars.D now, about the currying of templates
(i.e., the main topic here). I guess perhaps that was what you were
talking about?
Tuple unpacking syntax and template currying are two different things.
On 2011-02-01 10:12:44 +0100, Magnus Lie Hetland said:
On 2011-01-31 19:46:53 +0100, Simen kjaeraas said:
Magnus Lie Hetland mag...@hetland.org wrote:
Hm. Using code quite similar to you, supplying a lambda in the second
aliasing, I get this error:
something.d(93): Error: template
Magnus Lie Hetland mag...@hetland.org wrote:
Hm. Just to make sure this *is* a bug, and I'm not just being a dumbass
... this is a tiny program that illustrates the problem (i.e., gives the
error above). Perhaps the use of a local function here really is
prohibited...?
Maybe it is. It
Magnus Lie Hetland:
Yes, certainly. That was the point of this post -- that I misunderstood
what you were talking about in the original post (where you said this
topic right after my tuple unpacking paragraph) :)
I will eventually add to bugzilla a request for tuple unpacking syntax, see
Magnus Lie Hetland mag...@hetland.org wrote:
Sort of related (though perhaps only remotely) is the following, which
won't compile (Error: static assert Bad unary function: f(a) for type
int):
Not related. unaryFun and binaryFun are simply glorified string mixins,
and thus can only access
On 2011-02-01 16:00:16 +0100, Magnus Lie Hetland said:
import std.functional, std.stdio;
int f(int x) {return x;}
void main() {
alias unaryFun!(f(a)) g;
writeln(g(3));
}
Just to be clear -- I realize I could just have used unaryFun!f here
(or just f, for that matter). The
On 2011-02-01 16:09:22 +0100, Simen kjaeraas said:
Magnus Lie Hetland mag...@hetland.org wrote:
Sort of related (though perhaps only remotely) is the following, which
won't compile (Error: static assert Bad unary function: f(a) for type
int):
Not related. unaryFun and binaryFun are simply
Magnus Lie Hetland mag...@hetland.org wrote:
On 2011-02-01 16:09:22 +0100, Simen kjaeraas said:
Magnus Lie Hetland mag...@hetland.org wrote:
Sort of related (though perhaps only remotely) is the following, which
won't compile (Error: static assert Bad unary function: f(a) for type
int):
On 2011-02-01 16:41:33 +0100, Simen kjaeraas said:
That certainly makes sense. I just got thrown off by the example in
std.algorithm:
uint hashFun(string) { ... expensive computation ... }
string[] array = ...;
// Sort strings by hash, slow
sort!(hashFun(a) hashFun(b))(array);
The only way
If I have an enum of chars, and I have a variable that contains a generic char,
I may want to convert the second to an instance of the first one, safely (a
normal cast is enough to do it unsafely). Is it a good idea to give this
purpose to to!() (this idea is currently not implemented)?
bearophile Wrote:
If I have an enum of chars, and I have a variable that contains a generic
char, I may want to convert the second to an instance of the first one,
safely (a normal cast is enough to do it unsafely). Is it a good idea to give
this purpose to to!() (this idea is currently
Wow, thanks for the reply. Changing the 'enum dsize' to 'uint dsize = 4;' seems
to
produce some results...i guess it's working now (i have no way to verify it is
working but looks like bits are being rotated by rol). One thing, if i replace
dsize with 4 in all lines, the code compiles but again
Jesse Phillips:
I believe this is exactly what std.conv.to should do. It should be the safest
and recommended way to do conversions.
http://d.puremagic.com/issues/show_bug.cgi?id=5515
Bye,
bearophile
16 matches
Mail list logo
