[Issue 8061] std.algorithm.joiner breaks when used with InputRangeObject
http://d.puremagic.com/issues/show_bug.cgi?id=8061 --- Comment #5 from hst...@quickfur.ath.cx 2012-12-19 22:34:41 PST --- Found cause of problem: in std.format.formatRange(), there's a static if block that reads: ... else static if (isForwardRange!T && !isInfinite!T) auto len = walkLength(val.save); If this line is artificially modified to set len to some fixed value (say, the length of the joined string), then the OP's code works. This implies that val.save did not *really* save the range; it returned a copy that, when consumed, also consumes the original range. Digging deeper into the joiner code, the criteria for the joined range to be a forward range is if the range of ranges passed to joiner is both itself a forward range, and its subranges are also forward ranges. In theory, if these two conditions were really true, then the joined range should be a valid forward range. So this indicates that the problem lies with the array of InputRangeObjects passed to joiner. And here we discover the root of the problem: std.array.save, which defines .save for built-in arrays, always just returns the array, whereas the correct implementation would be to call .save on all array elements (if they are forward ranges). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7803] Regression(2.054) scope(success) in nothrow/@safe functions causes compile errors
http://d.puremagic.com/issues/show_bug.cgi?id=7803 --- Comment #9 from Kenji Hara 2012-12-19 17:32:32 PST --- (In reply to comment #8) > Now original code can be compiled as expected. > > Different from bug 6278, the internal catch and re-throwing which used for > scope(success) do not affect to whole code semantics. So I mark this "resolved > fixed". But, there is still internal semantic inconsistency: - Catching Throwable object in @safe code - Re-throwing Throwable object in nothrow code In these points, I couldn't resolve the issues cleanly... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7803] Regression(2.054) scope(success) in nothrow/@safe functions causes compile errors
http://d.puremagic.com/issues/show_bug.cgi?id=7803 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Kenji Hara 2012-12-19 17:25:29 PST --- Now original code can be compiled as expected. Different from bug 6278, the internal catch and re-throwing which used for scope(success) do not affect to whole code semantics. So I mark this "resolved fixed". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5115] std.typecons.scoped problems
http://d.puremagic.com/issues/show_bug.cgi?id=5115
Dmitry Olshansky changed:
What|Removed |Added
CC||dmitry.o...@gmail.com
--- Comment #12 from Dmitry Olshansky 2012-12-19
09:15:42 PST ---
(In reply to comment #11)
>
> There is another problem. You may want to pass the instance to another
> function, which is ok since the type will still be alive during that call:
>
> class C { }
> void func(C c) { }
> void main()
> {
> auto c = scoped!C();
> func(c); // ok, c is still alive here
> }
>
> Disabling implicit conversion (maybe by using your ProxyOf mixin) might be ok,
> but then we can no longer pass the instance around because `Scoped` is a
> voldemort type hidden inside the `scoped` function. E.g.:
>
> class C { }
> void func(C c) { }
> void funcScoped(??? c) { } // param needs to be a proper type
> void main()
> {
> auto c = scoped!C(); // voldemort type
> func(c); // error, no implicit conversion
> funcScoped(c); // would be ok if we knew what type c was
> }
>
> So if we disable implicit conversion we should probably introduce a Scoped
> type
> instead of a voldemort, so we can write:
>
> void funcScoped(ref Scoped!C c) { }
Even more interesting is emplacing inside of class instance (to avoid pointer
overhead while modeling composition):
class A{//A makes sure b & c are not escaped
Scoped!B b;
Scoped!C c;
}
Overall I think voldemort types are overpriced.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9187] New: -inline doesn't work with nested lambda functions
http://d.puremagic.com/issues/show_bug.cgi?id=9187
Summary: -inline doesn't work with nested lambda functions
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: egu...@gmail.com
--- Comment #0 from egu...@gmail.com 2012-12-19 09:02:49 PST ---
As the code below shows, dmd doesn't compile well when a lambda function is
nested another lambda(only fails if the result is used somehow later).
test case:
===
module foo;
import std.algorithm, std.range, std.array;
auto bar()
{
auto data = [5, 6, 7, 8],
test = map!( (x) => reduce!"a+b"(data[$-x..$]) )([1, 3]);
return array(test); // or "wrilteln(test);". if just "return test;" it
works.
}
==
When compile this module without -inline, it works. Otherwise it will be
failed:
foo.d(7): Error: function foo.bar is a nested function and cannot be accessed
from std.array.array!(MapResult!(__lambda2,int[])).array
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8622] Allow labeled breaks to work on *any* block
http://d.puremagic.com/issues/show_bug.cgi?id=8622
--- Comment #3 from Dmitry S 2012-12-19 07:38:20 PST ---
This feature is related to an "expectation bug", in that current spec is very
counterintuitive regarding labeled blocks. I added a couple of "See Also" bugs
where the current behavior of labeled blocks has tripped people up. The
problems are best demonstrated by a code sample (taken from those issues):
// Problem 1 (not a bug according to spec, but entirely counterintuitive).
int n;
label:
{
scope(exit) n++;
n=3;
}
writefln("n=%d should be 4", n); // Prints "n=3 should be 4"
// Problem 2: (counterintuitive AND a bug because should not compile).
block:
{
for (int i = 0; i < 10; i++) {
if (i == 5) break block;
}
writefln("Within block"); // This line IS printed.
}
writefln("Outside block");
The common problem for both cases is that a labeled block adds curly braces,
but the code behaves as if the braces weren't there.
In particular, adding a label to a block makes the block's scope disappear.
Consider how the first example would change if "label:" line is commented out.
That trips people up. It could be solved perhaps by simply prohibiting labels
on a block, but monarchdodra's suggestion seems like an really nice solution,
allowing for very intuitive flexibility (e.g. the second example is equivalent
to python's "else" clause on loops, more intuitive, and nearly as concise).
(Note that monarchdodra's suggestion critically depends on labeled blocks.
Unlabeled breaks definitely need to break out of the innermost loop or switch.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9186] Manifest constant can violate const correctness restrictions when empty
http://d.puremagic.com/issues/show_bug.cgi?id=9186 --- Comment #2 from monarchdo...@gmail.com 2012-12-19 07:26:55 PST --- (In reply to comment #1) > (In reply to comment #0) > > The basic use case is having: > > foo(const(char)[]); > > and trying to pass a > > immutable(char)[] to it. Which is illegal. > > Since when is that illegal? immutable and mutable both implicitly convert to > const. Typo. My apologies: > The basic use case is having: > foo(const(char)[][]); > and trying to pass a > "immutable(char)[][]" to it. Which is illegal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9186] Manifest constant can violate const correctness restrictions when empty
http://d.puremagic.com/issues/show_bug.cgi?id=9186 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-12-19 07:12:53 PST --- (In reply to comment #0) > The basic use case is having: > foo(const(char)[]); > and trying to pass a > immutable(char)[] to it. Which is illegal. Since when is that illegal? immutable and mutable both implicitly convert to const. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9186] New: Manifest constant can violate const correctness restrictions when empty
http://d.puremagic.com/issues/show_bug.cgi?id=9186
Summary: Manifest constant can violate const correctness
restrictions when empty
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-12-19 06:49:46 PST ---
The basic use case is having:
foo(const(char)[]);
and trying to pass a
immutable(char)[] to it. Which is illegal.
The problem here is that if you define a manifest constant that is empty, and
try to pass it to foo, the code will compile:
//
void main()
{
void foo(const(char)[][]);
alias Type = string[];
static assert(is(typeof(Type.init) == Type));
static if (is(typeof(foo(Type.init //Enter here !!!
{
Type Rbla() @property;
Type Lbla;
enum Type Ebla1 = [[]];
enum Type Ebla2 = ["hello"];
foo(Type.init); //OK!
foo(Rbla);
foo(Lbla);
foo(Ebla1); //OK!
foo(Ebla2);
}
}
//
Error: function dmd2.main.foo (const(char)[][]) is not callable using argument
types (string[])
Error: cannot implicitly convert expression (Rbla()) of type string[] to
const(char)[][]
Error: function dmd2.main.foo (const(char)[][]) is not callable using argument
types (string[])
Error: cannot implicitly convert expression (Lbla) of type string[] to
const(char)[][]
//
This may not seem like a "huge" problem in and out of itself. The *REAL*
problem lies in the static if:
"static if (is(typeof(foo(Type.init"
This code is explicitly written to find out if we can pass a variable of type
Type to foo. This is especially true for array types, which are the ones
vulnerable to this problem.
I'm marking as "Major", because phobos is vulnerable to the bug.
Found inside "put":
//
else static if (is(typeof(r.put((E[]).init
{
r((&e)[0..1]);
}
//
src\phobos\std\range.d(590): Error: cannot implicitly convert expression (&
e[0u..1u]) of type string[] to const(char)[][]
//
Current workaround is to use an lvalueof type function.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9185] New: Add note about where -op is useful
http://d.puremagic.com/issues/show_bug.cgi?id=9185 Summary: Add note about where -op is useful Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: pull Severity: enhancement Priority: P2 Component: DMD AssignedTo: andrej.mitrov...@gmail.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2012-12-19 06:41:00 PST --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9185] Add note about where -op is useful
http://d.puremagic.com/issues/show_bug.cgi?id=9185 --- Comment #1 from Andrej Mitrovic 2012-12-19 06:42:36 PST --- https://github.com/D-Programming-Language/dmd/pull/1392 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7803] Regression(2.054) scope(success) in nothrow/@safe functions causes compile errors
http://d.puremagic.com/issues/show_bug.cgi?id=7803 --- Comment #7 from github-bugzi...@puremagic.com 2012-12-19 06:41:36 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2926c0a493254efeaaff21fe920a00db58f46693 partially fix Issue 7803 - Regression(2.054) scope(success) in nothrow/@safe functions causes compile errors https://github.com/D-Programming-Language/dmd/commit/d6a2b1c95d8409e5e2ff0b60de64e2ee25283d96 Merge pull request #1388 from 9rnsr/fix7803 partially fix Issue 7803 - Regression(2.054) scope(success) in nothrow/@safe functions causes compile errors -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9046] typeof(T.init) should have the type T
http://d.puremagic.com/issues/show_bug.cgi?id=9046 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||monarchdo...@gmail.com Resolution||FIXED --- Comment #7 from monarchdo...@gmail.com 2012-12-19 05:49:29 PST --- Seems fixed to me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6057] Problem with defining enum in function
http://d.puremagic.com/issues/show_bug.cgi?id=6057 Andrej Mitrovic changed: What|Removed |Added Keywords|rejects-valid |link-failure, pull CC||andrej.mitrov...@gmail.com AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-12-19 04:12:06 PST --- https://github.com/D-Programming-Language/dmd/pull/1391 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7292] Exception and Error missing from object docs
http://d.puremagic.com/issues/show_bug.cgi?id=7292 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-12-19 03:36:16 PST --- https://github.com/D-Programming-Language/druntime/pull/337 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9184] New: std.algorithm.all fails to compile when providing a lambda
http://d.puremagic.com/issues/show_bug.cgi?id=9184
Summary: std.algorithm.all fails to compile when providing a
lambda
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jens.k.muel...@gmx.de
--- Comment #0 from jens.k.muel...@gmx.de 2012-12-19 03:22:50 PST ---
test.d
---
unittest
{
import std.algorithm;
assert(all!(a => a >= 0)([1, 2, 3]));
}
---
$ dmd -unittest -run test.d
fails with
Error: function test.__unittest3.not!(__lambda2).not!(int).not is a nested
function and cannot be accessed from std.algorithm.find!(not,int[]).find
Changing std.algorithm.all to
return find!((a) => !unaryFun!pred(a))(range).empty;
works.
Though I'm not sure whether this is an appropriate fix. Please advice that I
can create a pull request.
$ dmd | head -1
DMD64 D Compiler v2.060
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4479] Module Foo is in multiple files Foo
http://d.puremagic.com/issues/show_bug.cgi?id=4479 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2012-12-19 03:23:30 PST --- https://github.com/D-Programming-Language/dmd/pull/1389 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1161] [module] Access to private static members is allowed from other module.
http://d.puremagic.com/issues/show_bug.cgi?id=1161 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #8 from Andrej Mitrovic 2012-12-19 02:25:48 PST --- (In reply to comment #7) > Partially fixed in issue 5385. Which testcases did I miss? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
