On Monday, 21 November 2016 at 13:22:57 UTC, Paolo Invernizzi
wrote:
I'm not sure if it's the same as #15064 bug:
import std.array, std.range, std.algorithm;
immutable static foo = ["a", "b", "c"];
auto bar(R)(R r)
{
string s = r[1];
return s;
}
immutable static res =
I'm not sure if it's the same as #15064 bug:
import std.array, std.range, std.algorithm;
immutable static foo = ["a", "b", "c"];
auto bar(R)(R r)
{
string s = r[1];
return s;
}
immutable static res = foo.enumerate.map!bar().array;
std/typecons.d(526): Error:
On Thu, Jul 03, 2014 at 02:09:09AM +, safety0ff via Digitalmars-d-learn
wrote:
On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote:
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote:
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
The
Everything compiles fine except for function qux2:
http://dpaste.dzfl.pl/9d9187e0b450
Is this a bug or an enhancement for CTFE?
It would be really nice to have this feature because core.simd
has functions such as: void16 __simd(XMM opcode, void16 op1,
void16 op2, ubyte imm8);
Where all the
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote:
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
The question is now: how can the delegate be evaluated for the
return value but not for the enum?
On Thursday, 3 July 2014 at 02:02:19 UTC, safety0ff wrote:
On Thursday, 3 July 2014 at 01:55:14 UTC, safety0ff wrote:
Actually, this is an enhancement because adding:
enum b = blah
Makes them fail. :(
The question is now: how can the delegate be evaluated for the
return value but not for
I have this code: http://dpaste.dzfl.pl/dbe2a07f
It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`:
// Expected:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0, 1, 0, 3,
9, 3, 9, 0, 0),
On 17-Aug-12 20:27, David wrote:
I have this code: http://dpaste.dzfl.pl/dbe2a07f
It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`:
// Expected:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0, 3, 10, 3, 10, 0, 0), Vertex(0.5, 0.5, -0.5, 0,
Am 17.08.2012 18:36, schrieb Dmitry Olshansky:
On 17-Aug-12 20:27, David wrote:
I have this code: http://dpaste.dzfl.pl/dbe2a07f
It works perfectly fine, except for `t!(2, 10)` and `t!(1, 10)`:
// Expected:
[Vertex(-0.5, 0.5, 0.5, 0, 1, 0, 2, 10, 2, 10, 0, 0), Vertex(0.5, 0.5,
0.5, 0, 1, 0,
together the complete
sample and file it as CTFE bug here:
http://d.puremagic.com/issues/
--
Olshansky Dmitry
Johannes Pfau wrote:
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
OK, I found a workaround:
If I use
data[x] =
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK
Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
On 2011-12-22 14:39, Timon Gehr wrote:
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array
Jacob Carlborg wrote:
On 2011-12-22 14:39, Timon Gehr wrote:
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as
18 matches
Mail list logo
