[Issue 12015] std.digest.sha256 too
https://issues.dlang.org/show_bug.cgi?id=12015 Nick Sabalausky changed: What|Removed |Added CC||cbkbbej...@mailinator.com --- Comment #1 from Nick Sabalausky --- https://github.com/D-Programming-Language/phobos/pull/2129 --
[Issue 12661] New: [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661
Issue ID: 12661
Summary: [REG2.066a] std.regex with -debug causes linker errors
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: j...@red.email.ne.jp
This must be caused by one of the recent std.regex chages.
import std.regex;
void main() {
auto re = regex(`a`);
}
COMMAND:
dmd -debug reg2066regex.d
OUTPUT:
Error 42: Symbol Undefined
_D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList11addIntervalMFNaNeiikZk
reg2066regex.obj(reg2066regex)
Error 42: Symbol Undefined
_D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList8dropUpToMFNaNekkZk
reg2066regex.obj(reg2066regex)
Error 42: Symbol Undefined
_D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList8skipUpToMFNaNekkZk
ENVIRONMENT:
Windows 7 64bit
--
[Issue 12660] New: Wrong non-@nogc function invariant error
https://issues.dlang.org/show_bug.cgi?id=12660
Issue ID: 12660
Summary: Wrong non-@nogc function invariant error
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: diagnostic, rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
I don't understand this:
class Foo {
this() @nogc {}
@nogc invariant() {}
}
void main() {}
DMD 2.066alpha gives:
test.d(2,5): Error: @nogc function 'test.Foo.this' cannot call non-@nogc
function 'test.Foo.__invariant'
Currently this bug has severity "normal", but if this issue is valid then it
could be regarded as blocker for the release of 2.066.
--
[Issue 12293] forward is missing from std.algorithm's cheat-sheet
https://issues.dlang.org/show_bug.cgi?id=12293 Andrej Mitrovic changed: What|Removed |Added URL|https://github.com/D-Progra | |mming-Language/phobos/pull/ | |2099| Summary|forward should be moved to |forward is missing from |std.functional |std.algorithm's cheat-sheet --- Comment #7 from Andrej Mitrovic --- https://github.com/D-Programming-Language/phobos/pull/2099 --
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 --- Comment #6 from Andrej Mitrovic --- (In reply to monarchdodra from comment #5) > What !? > You suggested it. I just told you to go through with it. *Facepalm*. It appears I did. Sorry for this. :> --
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 --- Comment #5 from monarchdo...@gmail.com --- (In reply to Andrej Mitrovic from comment #4) > (In reply to Kenji Hara from comment #3) > > (In reply to Andrej Mitrovic from comment #2) > > > No, I've changed the title. See the history here: > > > https://issues.dlang.org/show_activity.cgi?id=12293 > > > > If the reason comes from just your feeling, I cannot agree with the title. > > I wasn't the one to suggest it, it was monarchdodra. What !? > AndrejMitrovic commented 4 days ago > https://issues.dlang.org/show_bug.cgi?id=12293 > > Honestly I think forward doesn't belong in std.algorithm. > It should likely belong to std.functional or a similar place. > Hence why I had to add a "utility" category. I'd rather we > just move the template out of std.algorithm though. You suggested it. I just told you to go through with it. > Originally I made the > pull that added 'forward' to the cheat-sheet of the std.algorithm page. I > can recreate this pull again if desired. Sure. > > std.algorithm.forward is in the same category of std.algorithm.move and > > swap. > > Why they are in std.algorithm module? Because in C++03, std::swap was in > > header. So in D, swap, move, and forward are in std.algorithm. > > That sounds reasonable to me then. Unless monarchdodra objects I'll recreate > the cheat-sheet pull. Sounds reasonable to me too. Revert back to how it was? --
[Issue 12659] New: Named mixin templates conflict
https://issues.dlang.org/show_bug.cgi?id=12659
Issue ID: 12659
Summary: Named mixin templates conflict
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: timon.g...@gmx.ch
With DMD 2.065, the following code fails to compile:
import std.stdio;
mixin template Foo(T){
T foo(T a){ return a; }
}
mixin Foo!int g;
mixin Foo!string g;
void main(){
writeln(foo(2));
writeln(foo("a"));
writeln(g.foo(2));
writeln(g.foo("a"));
}
Error: mixin tt.Foo!(string) conflicts with mixin tt.Foo!(int) at tt.d(6)
Similarly if two named mixins occur in different files:
module b;
mixin template Foo(T){
T foo(T a){ return a; }
}
mixin Foo!string g;
// ---
module c;
mixin template Foo(T){
T foo(T a){ return a; }
}
mixin Foo!int g;
// ---
import std.stdio;
import b,c;
void main(){
writeln(foo(2));
writeln(foo("a"));
writeln(g.foo(2));
writeln(g.foo("a"));
}
Error: b.Foo!(string) at b.d(5) conflicts with c.Foo!(int) at c.d(5)
Error: function b.Foo!(string).foo (string a) is not callable using argument
types (int)
Error: cannot implicitly convert expression (2) of type int to string
Error: b.Foo!(string) at b.d(5) conflicts with c.Foo!(int) at c.d(5)
Both examples should compile.
--
[Issue 12656] Some functions in std.ascii can be @nogc
https://issues.dlang.org/show_bug.cgi?id=12656 --- Comment #4 from Andrej Mitrovic --- (In reply to bearophile_hugs from comment #3) > (In reply to Andrej Mitrovic from comment #2) > > > I wish we implemented @nogc semantics before marking everything as @nogc. > > Without proper semantic cecks now, what's going to happen is we're going to > > have a million errors *after* everything is marked as @nogc at the moment > > @nogc semantics are properly implemented. > > I don't fully understand your points. Now @nogc semantics is already 80% > implemented. What's missing is stuff like Issue 12642, that Walter so far > has not commented on. Sorry, I was under the impression the semantics weren't in place. That's what I've read in the nogc pulls. Maybe things changed since then (a lot of changes go through every day). Disregard my rambling if I'm wrong. --
[Issue 12656] Some functions in std.ascii can be @nogc
https://issues.dlang.org/show_bug.cgi?id=12656 --- Comment #3 from bearophile_h...@eml.cc --- (In reply to Andrej Mitrovic from comment #2) > I wish we implemented @nogc semantics before marking everything as @nogc. > Without proper semantic cecks now, what's going to happen is we're going to > have a million errors *after* everything is marked as @nogc at the moment > @nogc semantics are properly implemented. I don't fully understand your points. Now @nogc semantics is already 80% implemented. What's missing is stuff like Issue 12642, that Walter so far has not commented on. --
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 --- Comment #4 from Andrej Mitrovic --- (In reply to Kenji Hara from comment #3) > (In reply to Andrej Mitrovic from comment #2) > > No, I've changed the title. See the history here: > > https://issues.dlang.org/show_activity.cgi?id=12293 > > If the reason comes from just your feeling, I cannot agree with the title. I wasn't the one to suggest it, it was monarchdodra. Originally I made the pull that added 'forward' to the cheat-sheet of the std.algorithm page. I can recreate this pull again if desired. > std.algorithm.forward is in the same category of std.algorithm.move and swap. > Why they are in std.algorithm module? Because in C++03, std::swap was in > header. So in D, swap, move, and forward are in std.algorithm. That sounds reasonable to me then. Unless monarchdodra objects I'll recreate the cheat-sheet pull. --
[Issue 11307] Make const(T).init and immutable(T).init lvalues
https://issues.dlang.org/show_bug.cgi?id=11307 --- Comment #2 from monarchdo...@gmail.com --- (In reply to Andrej Mitrovic from comment #1) > Does lvalueOf help with this? Not really. All `lvalueOf` does is provide an "external" lvalue you can test for your traits/contraints, but it doesn't actually provide an actual instance you can read or use. --
[Issue 12658] Emit informative diagnostic when file with a platform-incompatible extension is found
https://issues.dlang.org/show_bug.cgi?id=12658 Andrej Mitrovic changed: What|Removed |Added Keywords||pull --- Comment #1 from Andrej Mitrovic --- https://github.com/D-Programming-Language/dmd/pull/3504 --
[Issue 12650] Invalid codegen on taking lvalue of instance field initializ
https://issues.dlang.org/show_bug.cgi?id=12650 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/19af757daccd404b42c2bb9577362e0ff1441b89 fix Issue 12650 - Invalid codegen on taking lvalue of instance field initializing https://github.com/D-Programming-Language/dmd/commit/398ffcc3574504b0d266d79b061149a0f2820df8 Merge pull request #3500 from 9rnsr/fix12650 [REG2.066a] Issue 12650 - Invalid codegen on taking lvalue of instance field initializing --
[Issue 12211] Assignment expression is not an lvalue
https://issues.dlang.org/show_bug.cgi?id=12211 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2829415f71ab5d128980ac271fb0fe449f315983 Move test case for issue 12211 to runnable/assignable.d --
[Issue 12658] New: Emit informative diagnostic when file with a platform-incompatible extension is found
https://issues.dlang.org/show_bug.cgi?id=12658 Issue ID: 12658 Summary: Emit informative diagnostic when file with a platform-incompatible extension is found Product: D Version: D2 Hardware: All OS: Windows Status: NEW Keywords: diagnostic Severity: enhancement Priority: P1 Component: DMD Assignee: andrej.mitrov...@gmail.com Reporter: andrej.mitrov...@gmail.com E.g. see this user question here: http://forum.dlang.org/thread/belugxxgahqvbvcis...@forum.dlang.org This is not the first time users are confused about platform differences. A simple diagnostic can lead the users in the right way. --
[Issue 11372] getpagesize() should be in core.memory
https://issues.dlang.org/show_bug.cgi?id=11372 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #2 from Dmitry Olshansky --- > There is core.sys.posix.sys.shm.__getpagesize Actually on POSIX it's obtained via sysconf and _SC_PAGESIZE. Anyway I guess the point is that collector need to know page size anyway, and there is a global hidden somewhere deep that holds this size. --
[Issue 11372] getpagesize() should be in core.memory
https://issues.dlang.org/show_bug.cgi?id=11372 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic --- There is core.sys.posix.sys.shm.__getpagesize I guess you want a single wrapper for all platforms though? --
[Issue 11333] ICE: Cannot subtype 0-tuple with "alias this"
https://issues.dlang.org/show_bug.cgi?id=11333 Andrej Mitrovic changed: What|Removed |Added Keywords||ice CC||andrej.mitrov...@gmail.com Summary|Cannot subtype 0-tuple with |ICE: Cannot subtype 0-tuple |"alias this"|with "alias this" --
[Issue 12656] Some functions in std.ascii can be @nogc
https://issues.dlang.org/show_bug.cgi?id=12656 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic --- (In reply to Dmitry Olshansky from comment #1) > PRs are welcome. I wish we implemented @nogc semantics before marking everything as @nogc. Without proper semantic cecks now, what's going to happen is we're going to have a million errors *after* everything is marked as @nogc at the moment @nogc semantics are properly implemented. then it's going to be "good luck removing gc allocations now.". It's going to be too much work then. It's really a backwards development model. And it's being done on the master branch. --
[Issue 11367] Include paths on windows do not recursively expand env vars
https://issues.dlang.org/show_bug.cgi?id=11367 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic --- Probably blocked by: https://github.com/D-Programming-Language/dmd/pull/3421#issuecomment-39710429 --
[Issue 12656] Some functions in std.ascii can be @nogc
https://issues.dlang.org/show_bug.cgi?id=12656 Dmitry Olshansky changed: What|Removed |Added Keywords|rejects-valid | CC||dmitry.o...@gmail.com --- Comment #1 from Dmitry Olshansky --- It's a simple enhancement. rejects-valid is for code that should work but doesn't due to _compiler_ bug. In this case you simply want some functions to have attribute they don't yet have. PRs are welcome. --
[Issue 11356] isASCII for strings
https://issues.dlang.org/show_bug.cgi?id=11356 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic --- https://github.com/D-Programming-Language/phobos/pull/1665 I don't know why Walter was so hanged up about this. It's a simple function. I think it's worth reopening and maybe casting a vote in the forums. --
[Issue 11354] dmd2 wont compile properly under C++11/CLang
https://issues.dlang.org/show_bug.cgi?id=11354 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution|--- |INVALID --- Comment #2 from Andrej Mitrovic --- Marking as invalid. If we're moving to a self-hosting compiler then enabling C++11 compilation would give someone incentive to use C++11 syntax in the codebase, which would make auto-porting to D more difficult. --
[Issue 11103] w and d suffix for char literals too
https://issues.dlang.org/show_bug.cgi?id=11103 --- Comment #6 from Andrej Mitrovic --- (In reply to yebblies from comment #5) > (In reply to Andrej Mitrovic from comment #4) > > > > Can we get this as a pull request? It looks like low-hanging fruit to me. > > If you feel it's worthwhile feel free to take that patch and pull-request > it. I can't remember why I didn't go through with it... I'm sure there was > some kind of reason. :) I'll pass, unicode escapes me. When you have a 680 page book called "Unicode Explained" it's time to say "fuck it." :P --
[Issue 11405] rdmd should limit its tmp cache
https://issues.dlang.org/show_bug.cgi?id=11405 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc Summary|rdmd should limit it's tmp |rdmd should limit its tmp |cache |cache --- Comment #2 from bearophile_h...@eml.cc --- Renamed issue it's => its, hopefully for the better. --
[Issue 11103] w and d suffix for char literals too
https://issues.dlang.org/show_bug.cgi?id=11103 --- Comment #5 from yebblies --- (In reply to Andrej Mitrovic from comment #4) > > Can we get this as a pull request? It looks like low-hanging fruit to me. If you feel it's worthwhile feel free to take that patch and pull-request it. I can't remember why I didn't go through with it... I'm sure there was some kind of reason. :) --
[Issue 11405] rdmd should limit it's tmp cache
https://issues.dlang.org/show_bug.cgi?id=11405 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic --- (In reply to Martin Nowak from comment #0) > A simple solution would be to delete an existing folder with the same > first 2-3 bytes of the digest. This means we'd have to lock the folders > to synchronize different rdmd processes. I'd hate to make RDMD more complicated, but one idea is to make RDMD read its own config file just like DMD reads its .conf file, and then make this stuff configurable. --
[Issue 11253] std.algorithm.count is not nothrow
https://issues.dlang.org/show_bug.cgi?id=11253 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com Hardware|x86 |All Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com OS|Windows |All --- Comment #1 from Andrej Mitrovic --- https://github.com/D-Programming-Language/phobos/pull/2128 --
[Issue 12657] New: Regression (2.065): Running Phobos test-suite with -debug fails
https://issues.dlang.org/show_bug.cgi?id=12657
Issue ID: 12657
Summary: Regression (2.065): Running Phobos test-suite with
-debug fails
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
Not sure if Phobos or DMD regression, but:
$ rdmd --main -w -g -unittest --force std\algorithm.d
>
$ rdmd --main -w -debug -g -unittest --force std\algorithm.d
std\algorithm.d(9385): Error: 'std.algorithm.sort!("a > b",
cast(SwapStrategy)0, int[]).sort' is not nothrow
std\algorithm.d(9388): Error: 'std.algorithm.sort!("a < b",
cast(SwapStrategy)0, int[]).sort' is not nothrow
std\algorithm.d(9392): Error: 'std.algorithm.__unittestL9381_263.sort!(myComp,
cast(SwapStrategy)0, int[]).sort' is not
nothrow
std\algorithm.d(9381): Error: function 'std.algorithm.__unittestL9381_263' is
nothrow yet may throw
Either way it exposes that we're not running the test-suite with -debug.
--
[Issue 11177] parameterized enum can't be typed
https://issues.dlang.org/show_bug.cgi?id=11177 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 11103] w and d suffix for char literals too
https://issues.dlang.org/show_bug.cgi?id=11103 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #4 from Andrej Mitrovic --- (In reply to yebblies from comment #2) > Well, I implemented it. > > It was pretty easy, but I'm really not sure if it's worth doing after all. > > https://github.com/yebblies/dmd/tree/issue11103 Can we get this as a pull request? It looks like low-hanging fruit to me. --
[Issue 11023] DMD crashes
https://issues.dlang.org/show_bug.cgi?id=11023 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrej Mitrovic --- No test-case no cookie. --
[Issue 11307] Make const(T).init and immutable(T).init lvalues
https://issues.dlang.org/show_bug.cgi?id=11307 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic --- Does lvalueOf help with this? --
[Issue 12641] D1: __FILE__ and __LINE__ default argument behaviour
https://issues.dlang.org/show_bug.cgi?id=12641 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Hardware|x86_64 |All Resolution|--- |FIXED OS|Linux |All --- Comment #1 from Walter Bright --- Implemented: https://github.com/D-Programming-Language/dmd/commit/0a58064c6052964ad57135ef022949848ecfed37 --
[Issue 11511] DDoc - C variadic parameters cannot be properly documented
https://issues.dlang.org/show_bug.cgi?id=11511 --- Comment #1 from Andrej Mitrovic --- https://github.com/D-Programming-Language/dmd/pull/3503 --
[Issue 11511] DDoc - C variadic parameters cannot be properly documented
https://issues.dlang.org/show_bug.cgi?id=11511 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com Summary|DDoc - the parameter list |DDoc - C variadic |of a variadic function |parameters cannot be |cannot be documented|properly documented |properly| Severity|minor |normal --
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 --- Comment #3 from Kenji Hara --- (In reply to Andrej Mitrovic from comment #2) > No, I've changed the title. See the history here: > https://issues.dlang.org/show_activity.cgi?id=12293 If the reason comes from just your feeling, I cannot agree with the title. std.algorithm.forward is in the same category of std.algorithm.move and swap. Why they are in std.algorithm module? Because in C++03, std::swap was in header. So in D, swap, move, and forward are in std.algorithm. I know that std::swap, move, and forward are in header in C++11. But, std.functional module is for "functional programming" utilities. From the perspective, swap, move, and forward are not directly related to functional programming IMO. So, I think that moving it to the module is unreasonable change. --
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 --- Comment #2 from Andrej Mitrovic --- (In reply to Kenji Hara from comment #1) > (In reply to Gary Willoughby from comment #0) > > std.algorithm.forward is missing from the index at the top of > > http://dlang.org/phobos/std_algorithm.html > > If the issue is the un-listing of 'forward' function, why it should go > std.functional module? You should explain the reason. No, I've changed the title. See the history here: https://issues.dlang.org/show_activity.cgi?id=12293 --
[Issue 12651] TemplateArgsOf accepts nonsensical arguments
https://issues.dlang.org/show_bug.cgi?id=12651 Kenji Hara changed: What|Removed |Added Keywords||pull Component|Phobos |DMD --- Comment #1 from Kenji Hara --- This is compiler issue. https://github.com/D-Programming-Language/dmd/pull/3502 --
[Issue 12656] New: Some functions in std.ascii can be @nogc
https://issues.dlang.org/show_bug.cgi?id=12656
Issue ID: 12656
Summary: Some functions in std.ascii can be @nogc
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void main() @nogc {
import std.ascii: toLower, toUpper, isLower, isUpper;
auto c1 = toUpper('a');
auto c2 = toLower('A');
auto b1 = isLower('a');
auto b2 = isUpper('A');
}
DMD 2.066alpha gives:
test.d(3,22): Error: @nogc function 'D main' cannot call non-@nogc function
'std.ascii.toUpper!char.toUpper'
test.d(4,22): Error: @nogc function 'D main' cannot call non-@nogc function
'std.ascii.toLower!char.toLower'
test.d(5,22): Error: @nogc function 'D main' cannot call non-@nogc function
'std.ascii.isLower'
test.d(6,22): Error: @nogc function 'D main' cannot call non-@nogc function
'std.ascii.isUpper'
--
[Issue 12595] dup/idup shouldn't be property functions
https://issues.dlang.org/show_bug.cgi?id=12595
JR changed:
What|Removed |Added
CC||zor...@gmail.com
--- Comment #2 from JR ---
It's semantically ambiguous as duplicate can be both a noun and a verb.
I tend to think of .{i,}dup the noun way; something.duplicateOf; where whether
the .duplicateOf property "does" something or not remains up to implementation.
In abstract: the clerk has a stack of foos and you're asking for a .dup copy,
so he fetches one from the pile and hands it to you.
The opposite is naturally .duplicateThisForMe, from which perspective they
shouldn't be property functions, no.
--
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 --- Comment #1 from Kenji Hara --- (In reply to Gary Willoughby from comment #0) > std.algorithm.forward is missing from the index at the top of > http://dlang.org/phobos/std_algorithm.html If the issue is the un-listing of 'forward' function, why it should go std.functional module? You should explain the reason. --
[Issue 12655] New: foldRange
https://issues.dlang.org/show_bug.cgi?id=12655
Issue ID: 12655
Summary: foldRange
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
In the C++ STL there is an useful algorithm, that is not well named:
http://en.cppreference.com/w/cpp/algorithm/partial_sum
An usage example (it does more than just sums):
int main() {
std::vector v = {2, 2, 2, 2, 2, 2, 2, 2, 2, 2};
std::cout << "The first 10 even numbers are: ";
std::partial_sum(v.begin(), v.end(),
std::ostream_iterator(std::cout, " "));
std::cout << '\n';
std::partial_sum(v.begin(), v.end(), v.begin(), std::multiplies());
std::cout << "The first 10 powers of 2 are: ";
for (auto n : v) {
std::cout << n << " ";
}
std::cout << '\n';
}
The first 10 even numbers are: 2 4 6 8 10 12 14 16 18 20
The first 10 powers of 2 are: 2 4 8 16 32 64 128 256 512 1024
I suggest to add to std.algorithm a related algorithm (with a better name), a
lazy range like a reduce/fold that yields all the intermediate results. It is
the function present in Mathematica here, named FoldList, but the D version is
a lazy range, so a name for the D version is "foldRange" (or "reduceReange"):
http://reference.wolfram.com/mathematica/ref/FoldList.html
[a, b, ...].foldRange!f(seed)
==>
[seed, f(seed, a), f(f(seed, a), b), ...]
So given a range of length N it yields a range of length N + 1.
A version without seed could also be available.
Cumulative sums of the elements of an array:
[10, 20, 30, 40].foldRange!q{a + b}(0)
==>
[0, 10, 30, 60, 100]
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2].foldRange!q{a + b}(0)
==>
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]
--
[Issue 12654] New: std.typecons.ErrorMsg
https://issues.dlang.org/show_bug.cgi?id=12654 Issue ID: 12654 Summary: std.typecons.ErrorMsg Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bearophile_h...@eml.cc I suggest to add to std.typecons a cons named "ErrorMsg" (or a similar name) that is meant as a standard way to return an error condition when you don't want to use exceptions (useful in nothrow code). The advantage over Nullable is that it's not just "null" or a value. ErrorMsg is a value or a error message, so it informs what the cause of the failure is. To avoid generating many unused error message strings, I suggest the error message to be not just a string, but a 0-arguments callable that returns a string lazily. The advantage over using a user defined struct or Algebraic is that this is standard, so it gives a standard API, and the lazyness of the error message allows to save computation time to generate the error string. (A similar algebraic is used in other functional languages.) --
[Issue 10046] Wrong insertion of Tuple in associative array
https://issues.dlang.org/show_bug.cgi?id=10046 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej Mitrovic --- Can we get a pull for this? --
[Issue 12653] Add the getFunctionAttributes trait
https://issues.dlang.org/show_bug.cgi?id=12653 Andrej Mitrovic changed: What|Removed |Added Keywords||pull --- Comment #1 from Andrej Mitrovic --- https://github.com/D-Programming-Language/dmd/pull/3501 --
[Issue 11694] std.traits.SetFunctionAttributes does not conserve constness
https://issues.dlang.org/show_bug.cgi?id=11694 Andrej Mitrovic changed: What|Removed |Added Depends on||12653 --
[Issue 12653] Add the getFunctionAttributes trait
https://issues.dlang.org/show_bug.cgi?id=12653 Andrej Mitrovic changed: What|Removed |Added Blocks||11694 --
[Issue 12653] New: Add the getFunctionAttributes trait
https://issues.dlang.org/show_bug.cgi?id=12653 Issue ID: 12653 Summary: Add the getFunctionAttributes trait Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: andrej.mitrov...@gmail.com Reporter: andrej.mitrov...@gmail.com This will help fix https://issues.dlang.org/show_bug.cgi?id=11694 by avoiding relying on mangling to extract all function attributes, and as a consequence will also speed up compilation. --
[Issue 12650] Invalid codegen on taking lvalue of instance field initializ
https://issues.dlang.org/show_bug.cgi?id=12650 --- Comment #6 from Temtaime --- Yes, i missed "after" word. :) It's a git-head regression. Offtop: Thanks for your pr and contribution! --
[Issue 12650] Invalid codegen on taking lvalue of instance field initializ
https://issues.dlang.org/show_bug.cgi?id=12650 --- Comment #5 from Kenji Hara --- (In reply to Temtaime from comment #3) > So it's 2.065 reg. Note that, the test case has worked as intended with 2.065, but doesn't work with git-head. Right? Therefore the 'regression' is introduced in git-head development. So we should call it git-head (only) regression. --
[Issue 12650] Invalid codegen on taking lvalue of instance field initializ
https://issues.dlang.org/show_bug.cgi?id=12650
--- Comment #4 from Kenji Hara ---
(In reply to Temtaime from comment #3)
> Sorry, test case is wrong.
>
> void foo()(auto ref in S s) {}
>
> s must be auto ref.
>
> So it's 2.065 reg.
OK I understand, and the bug will be fixed by my PR.
--
[Issue 12650] Invalid codegen on taking lvalue of instance field initializ
https://issues.dlang.org/show_bug.cgi?id=12650
--- Comment #3 from Temtaime ---
Sorry, test case is wrong.
void foo()(auto ref in S s) {}
s must be auto ref.
So it's 2.065 reg.
--
[Issue 12293] forward should be moved to std.functional
https://issues.dlang.org/show_bug.cgi?id=12293 Andrej Mitrovic changed: What|Removed |Added Summary|std.algorithm.forward |forward should be moved to |documentation |std.functional Severity|trivial |normal --
[Issue 12642] Avoid some heap allocation cases for fixed-size arrays
https://issues.dlang.org/show_bug.cgi?id=12642 --- Comment #2 from bearophile_h...@eml.cc --- See also a comment: http://forum.dlang.org/post/ixrdixakezvtilemi...@forum.dlang.org --
[Issue 12650] Invalid codegen on taking lvalue of instance field initializ
https://issues.dlang.org/show_bug.cgi?id=12650 Kenji Hara changed: What|Removed |Added Keywords||pull, wrong-code Summary|GIT HEAD : Invalid codegen |Invalid codegen on taking ||lvalue of instance field ||initializ --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/3500 --
[Issue 12650] GIT HEAD : Invalid codegen
https://issues.dlang.org/show_bug.cgi?id=12650 --- Comment #1 from Kenji Hara --- (In reply to Temtaime from comment #0) > 2.065 output : 2 I think this is git-head only regression. Because the OP code cannot compile with 2.065: $ dmd -run test test.d(10): Error: function test.foo (ref const(S) s) is not callable using argument types (S) test.d(16): Error: template instance test.A.__ctor!() error instantiating (Assignment expression is changed to lvalue in git-head, by fixing issue 12211) --
[Issue 12652] New: Non-constant hash initializers should have a special-case diagnostic
https://issues.dlang.org/show_bug.cgi?id=12652
Issue ID: 12652
Summary: Non-constant hash initializers should have a
special-case diagnostic
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
-
int[int] x = [1:1];
void main() { }
-
test.d(2): Error: non-constant expression [1:1]
Associative arrays are supposed to be a first-class feature of D, but until we
make them CTFE-able we should emit better diagnostics (essentially do some
special-cases when hashes are involved).
The above code is something newcomers to D very frequently run into, and the
diagnostic doesn't really tell them what's wrong. Some suggestions:
-
Error: Associative array literals currently cannot be used to initialize
globals. Try using a module constructor instead.
-
This will at least point them to a workaround. Maybe a link to a page with a
workaround would be nice too.
--
[Issue 9148] 'pure' is broken
https://issues.dlang.org/show_bug.cgi?id=9148
--- Comment #4 from timon.g...@gmx.ch ---
(In reply to Xinok from comment #3)
> 'S.bar' is immutable, meaning it can only access immutable members of 'S',
> so the error is correct.
> ...
>
> Immutable functions can only read immutable members, so this error is
> actually correct.
>
(Indeed. I already noted this.)
> I think the trouble of member functions vs local functions may be a
> technicality: The struct object is seen as a hidden argument passed to the
> member function, whereas it's not seen this way with local functions. Because
> > pure functions can take mutable arguments, it will work for member
> functions. > But because the context pointer is not seen as an argument for
> local
> functions, it fails.
But obviously it is a hidden argument. There are no distinctions to be made
between local functions and member functions in this respect, and this is
especially important since delegates can be formed from both and their types
need to have a consistent interpretation.
> >
> > int delegate()pure s(){
> > int x;
> > int foo()pure{
> > // return x++; // error
> > return 2;
> > }
> > /+int bar()immutable pure{ // error
> > return 2;
> > }+/
> > return &foo;
> > }
>
> Function 'bar' actually compiles fine for me, no errors.
> ...
This is a change in behaviour since the bug was reported.
> >
> > void main(){
> > S s;
> > int delegate()pure dg = &s.foo;
> > // int delegate()pure immutable dg2 = &s.bar; // error
> > writeln(dg(), dg(), dg(), dg()); // 0123
> > immutable int delegate()pure dg3 = dg; // ok
> > writeln(dg3(), dg3(), dg3(), dg3()); // 4567
> > // static assert(is(typeof(cast()dg3)==int delegate() immutable pure));
> > // error
> > auto bar = &s.bar;
> > pragma(msg, typeof(bar)); // "int delegate() immutable pure"
> > }
>
> immutable int delegate()pure == immutable(int delegate()pure) != int
> delegate() immutable pure
> ...
Sure. Why is this relevant? The first 'error' appears to be fine now. The line
annotated 'ok' absolutely must fail. In case this is not obvious consider the
following code, which compiles and runs fine now:
class C{}
C foo(immutable C delegate()@safe pure dg)pure @safe{
return dg();
}
void main()@safe{
C c = new C();
struct S{
C c;
C foo()pure{ return c; }
}
S s=S(c);
immutable(C) d=foo(&s.foo);
assert(c is d);
}
I.e. this 'ok' is a loophole that allows unsafe type coercion.
The static assertion should pass. If top-level immutable is stripped using the
cast(), this should not affect the qualification of the context pointer
(because this way, it is @safe).
This is analogous to
immutable(int*) x;
static assert(is(typeof(cast()x)==immutable(int)*));
>
> Other than some confusion with member functions vs local functions,
(This confusion is actually the main part of the bug report and all the other
problems seem to be quite related to it.)
> I'm not sure there's actually any bugs here.
Some parser limitations appear to have been fixed since this issue was reported
but there are still plenty bugs as demonstrated above.
--
[Issue 12651] New: TemplateArgsOf accepts nonsensical arguments
https://issues.dlang.org/show_bug.cgi?id=12651
Issue ID: 12651
Summary: TemplateArgsOf accepts nonsensical arguments
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
CC: k.hara...@gmail.com
-
import std.traits;
struct S(T)
{
}
void main()
{
// compiles, but makes no sense
pragma(msg, TemplateArgsOf!(S!int, S, float));
}
-
I'm not sure whether this could also be a compiler bug. I'll CC kenji. The
following is the reduced test-case:
-
alias TemplateArgsOf(alias T : Base!Args, alias Base, Args...) = Args;
struct S(T) { }
void main()
{
pragma(msg, TemplateArgsOf!(S!int, S, float)); // prints 'int'
}
-
--
[Issue 9769] Remove opEquals from Object
https://issues.dlang.org/show_bug.cgi?id=9769 Jonathan M Davis changed: What|Removed |Added Depends on||12537 --
[Issue 12537] Templatizing opEquals results in infinite recursion in the compiler
https://issues.dlang.org/show_bug.cgi?id=12537 Jonathan M Davis changed: What|Removed |Added Blocks||9769 --
