[Issue 12437] ICE when passing undefined type to function pointer
https://d.puremagic.com/issues/show_bug.cgi?id=12437 Michael M changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12436] Opaque struct parameter type should not be allowed
https://d.puremagic.com/issues/show_bug.cgi?id=12436 --- Comment #3 from Andrej Mitrovic 2014-03-21 17:09:08 PDT --- (In reply to comment #2) > I would point out that references to opaque structs should compile. > > In your examples: > > S[] > S[]* > > Should compile, even if S is opaque, as these are just references to S. Yeah, my mistake. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12437] New: ICE when passing undefined type to function pointer
https://d.puremagic.com/issues/show_bug.cgi?id=12437
Summary: ICE when passing undefined type to function pointer
Product: D
Version: D2
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: michaelpm...@gmail.com
--- Comment #0 from Michael M 2014-03-21 16:37:04 PDT
---
void main() {
void function(int) bar;
bar(fake + 0);
}
main.d(3): Error: undefined identifier fake
dmd: hdrgen.c:764: virtual void PrettyPrintVisitor::visit(Type*): Assertion `0'
failed.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12436] Opaque struct parameter type should not be allowed
https://d.puremagic.com/issues/show_bug.cgi?id=12436 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer 2014-03-21 15:48:15 PDT --- I would point out that references to opaque structs should compile. In your examples: S[] S[]* Should compile, even if S is opaque, as these are just references to S. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12436] Opaque struct parameter type should not be allowed
https://d.puremagic.com/issues/show_bug.cgi?id=12436
--- Comment #1 from Andrej Mitrovic 2014-03-21
15:38:16 PDT ---
There are various other cases not caught yet, even for return types which are
partially checked now. Examples:
-
struct S;
S ret_f1(); // ok: fails
S[] ret_f2(); // should fail
S[1] ret_f4(); // should fail
S[]* ret_f3(); // should fail
void call_f1(S); // should fail
void call_f1(S[]); // should fail
void call_f1(S[1]); // should fail
void call_f1(S[]*); // should fail
void main() { }
-
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12436] New: Opaque struct parameter type should not be allowed
https://d.puremagic.com/issues/show_bug.cgi?id=12436 Summary: Opaque struct parameter type should not be allowed Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: accepts-invalid Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2014-03-21 15:21:38 PDT --- - struct Opaque; Opaque ret_func(); // ok: error void void_func(Opaque); // no error! - $ dmd test.d test.d(3): Error: cannot return opaque struct Opaque by value The void_func is not triggering errors, but it should. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12435] New: std.range.transposed for immutable matrix too
https://d.puremagic.com/issues/show_bug.cgi?id=12435
Summary: std.range.transposed for immutable matrix too
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-03-21 14:30:28 PDT ---
void main() {
import std.stdio: writeln;
import std.range: transposed;
immutable m = [[10, 20], [30, 40]];
auto t = m.transposed;
t.writeln;
}
dmd 2.066alpha gives:
...\dmd2\src\phobos\std\range.d(6705,23): Error: template std.array.popFront
cannot deduce function from argument types !()(immutable(int[])), candidates
are:
...\dmd2\src\phobos\std\array.d(569,6):std.array.popFront(T)(ref T[] a)
if (!isNarrowString!(T[]) && !is(T[] == void[]))
...\dmd2\src\phobos\std\array.d(592,6):std.array.popFront(C)(ref C[]
str) if (isNarrowString!(C[]))
...\dmd2\src\phobos\std\format.d(2556,17): Error: template instance
std.range.isInputRange!(Transposed!(immutable(int[])[])) error instantiating
...\dmd2\src\phobos\std\format.d(2781,5):instantiated from here:
enforceValidFormatSpec!(Transposed!(immutable(int[])[]), char)
...\dmd2\src\phobos\std\format.d(3082,16):instantiated from here:
formatValue!(LockingTextWriter, Transposed!(immutable(int[])[]), char)
...\dmd2\src\phobos\std\format.d(423,54):instantiated from here:
formatGeneric!(LockingTextWriter, Transposed!(immutable(int[])[]), char)
...\dmd2\src\phobos\std\stdio.d(1158,42):... (1 instantiations, -v to
show) ...
...\dmd2\src\phobos\std\stdio.d(2535,21):instantiated from here:
write!(Transposed!(immutable(int[])[]), char)
test.d(6,6):instantiated from here:
writeln!(Transposed!(immutable(int[])[]))
...\dmd2\src\phobos\std\format.d(3105,9): Warning: switch case fallthrough -
use 'goto default;' if intended
...\dmd2\src\phobos\std\format.d(3105,9): Warning: switch case fallthrough -
use 'goto default;' if intended
While this simpler program:
void main() {
import std.range: transposed;
immutable m = [[10, 20], [30, 40]];
auto t = m.transposed;
foreach (row; t) {}
}
Gives:
...\dmd2\src\phobos\std\range.d(6705,23): Error: template std.array.popFront
cannot deduce function from argument types !()(immutable(int[])), candidates
are:
...\dmd2\src\phobos\std\array.d(569,6):std.array.popFront(T)(ref T[] a)
if (!isNarrowString!(T[]) && !is(T[] == void[]))
...\dmd2\src\phobos\std\array.d(592,6):std.array.popFront(C)(ref C[]
str) if (isNarrowString!(C[]))
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12417] `toStringz` is fundamentally broken
https://d.puremagic.com/issues/show_bug.cgi?id=12417 --- Comment #2 from Denis Shelomovskij 2014-03-22 00:53:42 MSK --- (In reply to comment #1) > I.e. you must read the C API documentation about what happens to those passed > in pointer to data. I'm talking about completely different thing. No C functions document whether they store it's argument visible by GC during the call (at least because it can depend on calling convension), consider this call: --- SetCurrentDirectoryW(std.utf.toUTF16z(path)); --- It's incorrect as during `SetCurrentDirectoryW` call passed string may become invisible by GC and collected. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12417] `toStringz` is fundamentally broken
https://d.puremagic.com/issues/show_bug.cgi?id=12417 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2014-03-21 13:09:41 PDT --- As in ALL calls to C functions, you simply must be cognizant of the lifetime of any pointed to data passed to them. This is as true in D code passing stuff to C as in C code passing stuff to C. I.e. you must read the C API documentation about what happens to those passed in pointer to data. You must know what you're doing when calling C code. There's no one answer to this, and therefore no package we can devise to address this. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3882] Unused result of pure functions
https://d.puremagic.com/issues/show_bug.cgi?id=3882
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
--- Comment #35 from bearophile_h...@eml.cc 2014-03-21 12:37:55 PDT ---
Now this code:
int foo(int x) pure nothrow {
return x - 1;
}
void main() {
foo(5);
}
Gives:
test.d(5,8): Warning: Call to strictly pure function test.foo discards return
value of type int, prepend a cast(void) if intentional
Issue fixed.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12434] New: std.algorithm.sum of immutable array too
https://d.puremagic.com/issues/show_bug.cgi?id=12434
Summary: std.algorithm.sum of immutable array too
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-03-21 12:00:30 PDT ---
void main() {
import std.algorithm: sum, map;
auto a1 = [10, 20];
auto t1 = sum(a1); // OK
immutable a2 = [10, 20];
auto t2 = sum(a2); // Error
auto t3 = a2.map!(x => x).sum; // Error
}
dmd 2.066alpha:
...\dmd2\src\phobos\std\algorithm.d(1087,15): Error: template std.algorithm.sum
cannot deduce function from argument types !()(immutable(int)[],
immutable(int)), candidates are:
...\dmd2\src\phobos\std\algorithm.d(1079,6):std.algorithm.sum(R)(R r)
if (isInputRange!R && !isInfinite!R && is(typeof(r.front + r.front)))
...\dmd2\src\phobos\std\algorithm.d(1090,6):std.algorithm.sum(R, E)(R
r, E seed) if (isInputRange!R && !isInfinite!R && is(typeof(seed = seed +
r.front)))
test.d(6,18): Error: template instance std.algorithm.sum!(immutable(int)[])
error instantiating
...\dmd2\src\phobos\std\algorithm.d(1087,15): Error: template std.algorithm.sum
cannot deduce function from argument types !()(MapResult!(__lambda1,
immutable(int)[]), immutable(int)), candidates are:
...\dmd2\src\phobos\std\algorithm.d(1079,6):std.algorithm.sum(R)(R r)
if (isInputRange!R && !isInfinite!R && is(typeof(r.front + r.front)))
...\dmd2\src\phobos\std\algorithm.d(1090,6):std.algorithm.sum(R, E)(R
r, E seed) if (isInputRange!R && !isInfinite!R && is(typeof(seed = seed +
r.front)))
test.d(7,30): Error: template instance std.algorithm.sum!(MapResult!(__lambda1,
immutable(int)[])) error instantiating
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12432] Diagnostic on argument count mismatch for ranges and opApply should improve
https://d.puremagic.com/issues/show_bug.cgi?id=12432 Andrej Mitrovic changed: What|Removed |Added Keywords||pull --- Comment #1 from Andrej Mitrovic 2014-03-21 11:35:40 PDT --- https://github.com/D-Programming-Language/dmd/pull/3396 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12113] A nothrow std.utf.decode with substitution on bad encoding
https://d.puremagic.com/issues/show_bug.cgi?id=12113 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright 2014-03-21 11:28:17 PDT --- The relevant spec: http://www.unicode.org/versions/Unicode6.2.0/UnicodeStandard-6.2.pdf -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12433] New: Allow forward referencing IFTI types in template argument list
https://d.puremagic.com/issues/show_bug.cgi?id=12433
Summary: Allow forward referencing IFTI types in template
argument list
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir Panteleev 2014-03-21
20:17:57 EET ---
Consider this hypothetical example:
/ test.d /
T[] copyArray(T=I, I)(I[] input)
{
auto result = new T[input.length];
foreach (n, ref i; input)
result[n] = i;
return result;
}
void main()
{
// copy as is
int[] r1 = copyArray([1, 2, 3]);
// copy to another type
long[] r2 = copyArray!long([1, 2, 3]);
}
//
There is currently no way to get this code to work, without either declaring an
overload for copyArray, or replacing T=I with T=SomeDummyType and later
checking to see if something was explicitly passed or not.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3882] Unused result of pure functions
https://d.puremagic.com/issues/show_bug.cgi?id=3882 --- Comment #34 from github-bugzi...@puremagic.com 2014-03-21 10:47:49 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1042f245137ad4c4fd9506261fa8a2000f21df2c Merge pull request #3342 from nordlow/warn-unused-returns Issue 3882: Add warning for unused non-void returns of strictly pure function calls -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12432] New: cryptic error using splitter in foreach
https://d.puremagic.com/issues/show_bug.cgi?id=12432
Summary: cryptic error using splitter in foreach
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jlqu...@optonline.net
--- Comment #0 from Jerry Quinn 2014-03-21 10:40:52 PDT
---
import std.algorithm;
void foo(string line) {
foreach (int i,string tok; splitter(line, " ")) {}
}
~/dmd2/linux/bin64/dmd -c junk.d
junk.d(5): Error: cannot infer argument types
This is dmd 2.065.0 on ubuntu 64 bit.
Removing the int i fixes the problem.
I think I recall seeing something about trying to use an index variable with a
forward range. It's nice to be able to use the var, even if I'm not trying to
index into the range.
More importantly, the error message is completely opaque.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12427] Regression (2.066 git-head): Building druntime fails with -debug=PRINTF
https://d.puremagic.com/issues/show_bug.cgi?id=12427 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12427] Regression (2.066 git-head): Building druntime fails with -debug=PRINTF
https://d.puremagic.com/issues/show_bug.cgi?id=12427 --- Comment #2 from github-bugzi...@puremagic.com 2014-03-21 08:30:55 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/fdecc7d3554d8a13eb1139a1a00efd29aa31a698 Fix Issue 12427 - Building druntime with -debug=PRINTF fails. https://github.com/D-Programming-Language/druntime/commit/642f95ec0e0348b82c0871f55b9b5e4d1a6cb07a Merge pull request #748 from AndrejMitrovic/Fix12427 Issue 12427 - Building druntime with -debug=PRINTF fails. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12431] New: SIMD vector in struct ICE
https://d.puremagic.com/issues/show_bug.cgi?id=12431
Summary: SIMD vector in struct ICE
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: john.loughran.col...@gmail.com
--- Comment #0 from John Colvin 2014-03-21
14:17:28 GMT ---
import core.simd;
import std.stdio;
struct A
{
float4 x;
}
void main()
{
A a;
writeln(a.x.array);
}
Internal error: e2ir.c 90
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12430] New: non compile-time __simd opcode causes ICE
https://d.puremagic.com/issues/show_bug.cgi?id=12430
Summary: non compile-time __simd opcode causes ICE
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: john.loughran.col...@gmail.com
--- Comment #0 from John Colvin 2014-03-21
12:47:31 GMT ---
import core.simd;
void main()
{
float4 a;
auto op = XMM.RSQRTPS;
auto b = __simd(op, a);
}
Internal error: backend/el.c 2744
If, as is correct, enum is used for the opcode, there is no error.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12429] New: SIMD vector type errors are too eager
https://d.puremagic.com/issues/show_bug.cgi?id=12429
Summary: SIMD vector type errors are too eager
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: john.loughran.col...@gmail.com
--- Comment #0 from John Colvin 2014-03-21
12:43:27 GMT ---
template MakeVecType(Base, ubyte length)
{
mixin(`alias MakeVecType = ` ~ Base.stringof ~ length.to!string() ~ `;`);
}
alias BaseT = float;
static if(is(MakeVecType!(BaseT, 8)))
{
enum vecLength = 8;
}
else static if(is(MakeVecType!(BaseT, 4)))
{
enum vecLength = 4;
}
else static if(is(MakeVecType!(BaseT, 2)))
{
enum vecLength = 2;
}
else
{
static assert(false, "Insufficient SIMD support");
}
fails to compile with the error
Error: AVX vector types not supported
If my understanding is correct, this shouldn't be an error. The first is(...)
should just evaluate to false.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5074] array(immutable(int)[]) ==> int[]
https://d.puremagic.com/issues/show_bug.cgi?id=5074 --- Comment #9 from bearophile_h...@eml.cc 2014-03-21 05:36:04 PDT --- (In reply to comment #7) > It doesn't have to! If array is pure, takes some form of const(int)[], and > returns int[] then the result will implicitly convert to immutable! See Issue 12282 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5881] Spellchecker should include built-in keywords
https://d.puremagic.com/issues/show_bug.cgi?id=5881 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from bearophile_h...@eml.cc 2014-03-21 05:33:08 PDT --- (In reply to comment #2) > I think this is of questionable value See also Issue 6946 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8755] Change the order of reduce arguments
https://d.puremagic.com/issues/show_bug.cgi?id=8755 --- Comment #21 from bearophile_h...@eml.cc 2014-03-21 05:32:04 PDT --- (In reply to comment #20) > I'm not sure it's a fair reference, because Phobos doesn't "do" anything, it > just provides function. I'd be willing to bet there is a fair amount of it > being used out there. OK. One usage case I can think of is to compute the sum and count of an input range, to compute its average :-) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5074] array(immutable(int)[]) ==> int[]
https://d.puremagic.com/issues/show_bug.cgi?id=5074 --- Comment #8 from monarchdo...@gmail.com 2014-03-21 05:18:13 PDT --- (In reply to comment #7) > It doesn't have to! If array is pure, takes some form of const(int)[], and > returns int[] then the result will implicitly convert to immutable! I had thought of that, but it could still break in subtle ways in regards to inference. Instead of being immutable by default, you have to trigger the conversion. EG. break: //--- immutable a = "hello; auto b = array(a); //is now an dchar[], not dstring :� ... dstring c = b; //error! // I *do* think it's very nice design though, and it *really* shows the strength of pure functions. And there remember there being requests for things like "specify the constness of array", so this change would also fix that. But it would still be a breaking change. A good change (IMO), but still a breaking one. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8755] Change the order of reduce arguments
https://d.puremagic.com/issues/show_bug.cgi?id=8755 --- Comment #20 from monarchdo...@gmail.com 2014-03-21 05:07:58 PDT --- (In reply to comment #18) > What I don't like is to give only 1 single scalar argument if you have N > functions and then implicitly multiply the single seed N times. Similar > implicit behaviours look handy, but they make the code less clear, and later > usually they find some way to bite your rump. I've already agreed to that point, and will be removing the functionality. Furthermore, I doubt it provides any real feature: We never call reduce with so many functions that this would be justified. > On the other hand I think that it's uncommon to give more than one function to > reduce/fold. So this whole sub-feature is could even be chopped away, > simplifying fold. When you say "sub-feature", are you talking about about the "1-seed" thing, or having multiple functions/ If it's multiple functions, then I have to say that it's an opt-in feature, and it works anyways. It's not actually complicated to implement, and it buys us nothing to remove it. Why want to chop it? I've used it before. It's nice. If it's the single seed for multiple functions, yeah. > How many real usages of multi-function reduce to you have in Phobos? I'm not sure it's a fair reference, because Phobos doesn't "do" anything, it just provides function. I'd be willing to bet there is a fair amount of it being used out there. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5881] Spellchecker should include built-in keywords
https://d.puremagic.com/issues/show_bug.cgi?id=5881 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies 2014-03-21 23:02:06 EST --- (In reply to comment #1) > Everyone: is there a singular list of all the keywords somewhere? Inside the compiler or one of the alternative lexers. I think this is of questionable value - basic syntax highlighting makes this unnecessary. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5074] array(immutable(int)[]) ==> int[]
https://d.puremagic.com/issues/show_bug.cgi?id=5074 yebblies changed: What|Removed |Added Status|RESOLVED|REOPENED CC||yebbl...@gmail.com Resolution|WONTFIX | --- Comment #7 from yebblies 2014-03-21 22:59:24 EST --- (In reply to comment #5) > (In reply to comment #4) > > However, this would be a change of behavior, which may or may not be an > > improvement, and may or may not break code. > > It will break code. > > immutable(int)[] a = ...; > immutable(int)[] b = array(a); > > This breaks if array returns int[]. > It doesn't have to! If array is pure, takes some form of const(int)[], and returns int[] then the result will implicitly convert to immutable! -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8755] Change the order of reduce arguments
https://d.puremagic.com/issues/show_bug.cgi?id=8755 --- Comment #19 from bearophile_h...@eml.cc 2014-03-21 04:03:46 PDT --- See also Issue 10670 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5325] Mutable references to const/immutable/shared classes
https://d.puremagic.com/issues/show_bug.cgi?id=5325 Denis Shelomovskij changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #5 from Denis Shelomovskij 2014-03-21 15:03:05 MSK --- What is the state of this? Is there any NG discussion? Lack of this feature is really disappointing and feels like a typesystem defect. P.S. (In reply to comment #4) > How does C# deal with this? By not providing any type qualifiers. Its `const` works like enum and `volatile` only affect variable load/store. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8755] Change the order of reduce arguments
https://d.puremagic.com/issues/show_bug.cgi?id=8755
--- Comment #18 from bearophile_h...@eml.cc 2014-03-21 03:46:15 PDT ---
(In reply to comment #17)
> it would be possible to make `Tuple` and
> `args...` co-exist as input argument style. EG:
>
> r = a.fold!("a + b", "a + b * b")(0.0, 0.0); //OK!
> r = a.fold!("a + b", "a + b * b")(tuple(0.0, 0.0)); //OK! too!
>
> The second one is more verbose, but I see its justified if your seed is
> already
> in the form of a tuple.
What I don't like is to give only 1 single scalar argument if you have N
functions and then implicitly multiply the single seed N times. Similar
implicit behaviours look handy, but they make the code less clear, and later
usually they find some way to bite your rump.
On the other hand I think that it's uncommon to give more than one function to
reduce/fold. So this whole sub-feature is could even be chopped away,
simplifying fold.
How many real usages of multi-function reduce to you have in Phobos?
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12428] New: Regression (2.066 git-head): toUpper is corrupting input data (modifying immutable strings)
https://d.puremagic.com/issues/show_bug.cgi?id=12428
Summary: Regression (2.066 git-head): toUpper is corrupting
input data (modifying immutable strings)
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir Panteleev 2014-03-21
12:24:40 EET ---
/ test.d
import std.array;
import std.string;
void main()
{
auto s = "abcdefghij".replicate(300);
s = s[0..10];
toUpper(s);
assert(s == "abcdefghij");
}
/
Introduced in https://github.com/D-Programming-Language/phobos/pull/1957
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8755] Change the order of reduce arguments
https://d.puremagic.com/issues/show_bug.cgi?id=8755
--- Comment #17 from monarchdo...@gmail.com 2014-03-21 01:51:41 PDT ---
(In reply to comment #14)
> >Furthermore, it also improves usability by making the seeds passed by
> >parameter pack, instead of forcing the use of a tuple.<
>
> OK. (Despite in a modern language tuples should be built-in, so using them
> should be natural, common, and syntactically very cheap. In
> Python/Haskell/Scala code you don't see functions that refrain from accepting
> a
> tuple).
The current most spread phobos style is to accept arguments via vararg, and to
return tuples when you need to return several args, so I tried to stick to
that.
I'm not sure it is possible to accept either a Tuple (that "auto expands"
later), and varargs, without potentially creating some ambiguity.
> >Finally, it allows using only 1 seed, in which case, the same seed is
> >replicated and is used for all the functions.
>
> This is from the unittests:
>
> // Compute sum and sum of squares in one pass.
> // This can be used to compute get the average and standard deviation.
> // A single seed (0.0) is passed, but it is optional
> // if the range is not empty.
> r = a.fold!("a + b", "a + b * b")(0.0);
> assert(approxEqual(r[0], 35)); // sum
> assert(approxEqual(r[1], 233)); // sum of squares
>
> This is ambiguous, it seems that "a + b" has a seed while "a + b * b" doesn't
> have a seed. So in my opinion if you give N function then you need to give 0
> seeds, or one N-tuple, or N seeds. So I don't like this.
You think? It made sense to me. I'll have to ask for more input on this. That
said, if we turn it down, then it would be possible to make `Tuple` and
`args...` co-exist as input argument style. EG:
r = a.fold!("a + b", "a + b * b")(0.0, 0.0); //OK!
r = a.fold!("a + b", "a + b * b")(tuple(0.0, 0.0)); //OK! too!
The second one is more verbose, but I see its justified if your seed is already
in the form of a tuple.
So I think you sold me on it.
> >Oh yeah, also, I made it so that when no seed is given, it is an Error to
> >use an empty range. This is the only case of deviation, but I think having
> >nothrow justifies it.
>
> I am not sure this is a good idea. Throwing when you give no seed is probably
> acceptable. But I am not sure.
It's a deviation, but I think it's justified. It makes the code nothrow, and
quite frankly, accessign an empty range is an Error, so end of story.
The only argument I'd accept in its favor is stability with reduce, but if we
could redesign, I'd never accept throwing an exception in such a case.
> > "iterables" are not supported anymore.
>
> If by "iterables" you mean that fold doesn't accept opApply-based iterables
> then I am against this change, I have plenty of code that opApply-based and I
> sometimes use reduce on them.
OK. I can work them back in.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12427] Regression (2.066 git-head): Building druntime fails with -debug=PRINTF
https://d.puremagic.com/issues/show_bug.cgi?id=12427 Andrej Mitrovic changed: What|Removed |Added Keywords||pull AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2014-03-21 01:50:55 PDT --- https://github.com/D-Programming-Language/druntime/pull/748 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12427] New: Regression (2.066 git-head): Building druntime fails with -debug=PRINTF
https://d.puremagic.com/issues/show_bug.cgi?id=12427 Summary: Regression (2.066 git-head): Building druntime fails with -debug=PRINTF Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2014-03-21 01:47:30 PDT --- src\rt\lifetime.d(989): Error: cannot pass dynamic arrays to extern(C) vararg functions src\rt\lifetime.d(1017): Error: template instance rt.lifetime._d_newarrayOpT! (_d_newarrayT) error instantiating src\rt\lifetime.d(989): Error: cannot pass dynamic arrays to extern(C) vararg functions src\rt\lifetime.d(1042): Error: template instance rt.lifetime._d_newarrayOpT! (_d_newarrayiT) error instantiating -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8755] Change the order of reduce arguments
https://d.puremagic.com/issues/show_bug.cgi?id=8755 --- Comment #16 from monarchdo...@gmail.com 2014-03-21 01:44:56 PDT --- (In reply to comment #15) > Why is reduce (sorry, fold) allowing multiple function arguments in the first > place? > > If you want to compose functions to avoid another O(n) iteration, then you > should compose the reduce function to return a tuple yourself. > > That way it is clear what the code is doing, instead of this magic N-tuple > special case return type. You shouldn't have to need to look at what the code is doing. It's a library. We accept multiple function arguments because: auto minmax = myRange.reduce!(min, max)(); Is incredibly straight forward and convenient. That said, the design doesn't actually prevent you from doing it as you are asking for: //- auto first = tuple(myRange.front, myRange.front); myRange.popFront(); auto minmax = reduce!((a, b) => tuple(min(a[0], b), max(a[1], b)))(first, myRange); writeln(minmax); // It works, but you'll have a tough time selling it to me. The only argument in favor of this approach, is if you need the return type to be different from the tuple type. But as I said, both approaches can co-exist, so why hold out? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
