[Issue 14045] Redo the forums entry page and links
https://issues.dlang.org/show_bug.cgi?id=14045 --- Comment #11 from Andrei Alexandrescu --- (In reply to Walter Bright from comment #10) > I think it would be too disruptive to rename the NNTP forums, though > changing them for forum.dlang.org would be fine. Agreed. Vladimir, is some sort of redirection/aliasing possible? --
[Issue 14045] Redo the forums entry page and links
https://issues.dlang.org/show_bug.cgi?id=14045 --- Comment #10 from Walter Bright --- (In reply to Vladimir Panteleev from comment #9) > Which forums should be kept on the index? > > C++ stuff - remove? Yes > DTL - remove? Yes > DWT - move up to "Ecosystem"? Why? > DMDScript - remove? Yes > digitalmars.empire - remove? Yes > There's also some stale mailing lists, or mailing lists only used for GitHub > announcements (phobos, dmd-concurrency), keep/remove? > > CC Walter Bright I think it would be too disruptive to rename the NNTP forums, though changing them for forum.dlang.org would be fine. --
[Issue 7687] Ddoc should be able to generate "Jump to" links
https://issues.dlang.org/show_bug.cgi?id=7687 Doug Nickerson changed: What|Removed |Added CC||tachyon...@gmail.com --- Comment #8 from Doug Nickerson --- More minor, but whenever or however "Jump to" links are updated in the future, I noticed the ordering seems to be off: If there are more than 9 overloads, the Jump to links read: "10 11 2 3 4 5 6 7 8 9" In other words, seems to be sorted lexicographically by the string value rather than numerically by the index value. An example of this can be seen at: http://dlang.org/phobos/std_conv.html#.toImpl --
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556 --- Comment #11 from dennis.m.ritc...@mail.ru --- > Surely this is an attempt to maintain compatibility with C? With C++ :) --
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556
--- Comment #10 from dennis.m.ritc...@mail.ru ---
(In reply to Ketmar Dark from comment #9)
> (In reply to dennis.m.ritchie from comment #7)
> > I suggest to implement such a syntax for declaring multidimensional arrays:
> >
> > auto array = new int[11](4, 8, 6, 13 /* The length of the other
> > subarrays on request */);
>
> you can do almost the same with templates.
>
> auto DNew(T, A...) () if (A.length > 0) {
> template A2S(A...) {
> import std.conv : to;
> static if (A.length == 0)
> enum A2S = "";
> else
> enum A2S = to!string(A[0])~","~A2S!(A[1..$]);
> }
> import std.array : replicate;
> return mixin("new "~T.stringof~"[]".replicate(A.length)~"("~A2S!A~")");
> }
>
>
> void main () {
> import std.stdio;
> auto a = DNew!(int, 5, 6, 7);
> a[2][3][4] = 42;
> writeln(a[2][3][]);
> }
Yes, do that D is really easy!
Then why in the D still has not gotten rid of this hardcore syntax :)
auto a = new int[][][](5, 6, 7);
Surely this is an attempt to maintain compatibility with C?
--
[Issue 14606] [REG2.067.0] Bad code with -inline and structs
https://issues.dlang.org/show_bug.cgi?id=14606 --- Comment #4 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/10fc5c4227911d4abf4727a283e56afa0aedd783 fix Issue 14606 - Bad code with -inline and structs The wrong-code had caused by the combination of special memset expression `(struct = 0)` and inlining field variable initialization with NRVO. The extended inlining had introduced ConstructExp(ref_var, 0), but it was wrongly handled as reference initialization in AssignExp::toElem(). To fix that, use `BlitExp` for the memset expression always, and avoid confusion with the ref initialization. https://github.com/D-Programming-Language/dmd/commit/58047b08977cc82f09238e8ac6300dd5158a7acb Merge pull request #4683 from 9rnsr/fix14606 [REG2.067.0] Issue 14606 - Bad code with -inline and structs --
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556
--- Comment #9 from Ketmar Dark ---
(In reply to dennis.m.ritchie from comment #7)
> I suggest to implement such a syntax for declaring multidimensional arrays:
>
> auto array = new int[11](4, 8, 6, 13 /* The length of the other
> subarrays on request */);
you can do almost the same with templates.
auto DNew(T, A...) () if (A.length > 0) {
template A2S(A...) {
import std.conv : to;
static if (A.length == 0)
enum A2S = "";
else
enum A2S = to!string(A[0])~","~A2S!(A[1..$]);
}
import std.array : replicate;
return mixin("new "~T.stringof~"[]".replicate(A.length)~"("~A2S!A~")");
}
void main () {
import std.stdio;
auto a = DNew!(int, 5, 6, 7);
a[2][3][4] = 42;
writeln(a[2][3][]);
}
--
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556 --- Comment #8 from dennis.m.ritc...@mail.ru --- > Current ambituity syntax new int[2][1] should be deprecated, removed, > and then we can reuse it for static array allocation. Quickly already, the problems with static arrays in D are boring. --
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556 dennis.m.ritc...@mail.ru changed: What|Removed |Added CC||dennis.m.ritc...@mail.ru --- Comment #7 from dennis.m.ritc...@mail.ru --- (In reply to Kenji Hara from comment #3) > (In reply to bearophile_hugs from comment #1) > > I suspect that the array creation syntax is an unfixable mess. > > > > new int[256][256] can also be generate a pointer to fixed size array > > int[256][256]. > > I think all dynamic array allocation should be writtten as: > > int[][](1, 2) > > Current ambituity syntax new int[2][1] should be deprecated, removed, > and then we can reuse it for static array allocation. Now D is used for a multidimensional array syntax :) auto arrray = new int[][][][][][][][][][][](4, 8, 6, 13 /* ... The length of the other subarrays on request */); I suggest to implement such a syntax for declaring multidimensional arrays: auto array = new int[11](4, 8, 6, 13 /* The length of the other subarrays on request */); P.S. The syntax for declaring multidimensional arrays, needs work! --
[Issue 1238] Private identifiers in imported modules create conflicts with public ones
https://issues.dlang.org/show_bug.cgi?id=1238 --- Comment #10 from Ketmar Dark --- (In reply to Timothee Cour from comment #9) > Faced this again, this is a serious bug that's 8 years old !! > > What are the difficulties involved in fixing this? exactly zero difficulties. Kenji's PR3416 works like a charm, i'm using it since a long time ago, and has ZERO problems with it. except some missing imports in some projects, which i reported and authors happily fixed — and that couldn't be found without the patch, accumulating bugs and "we can't merge the patch as it will break user code" murmur. i'm almost sure now that modules are broken by intention, as having a solution for such a long time and happily ignoring it (and me writing about it) looks like a plan, not like an oversight. so calm down and get used to it, it will never be fixed. --
[Issue 1238] Private identifiers in imported modules create conflicts with public ones
https://issues.dlang.org/show_bug.cgi?id=1238 Timothee Cour changed: What|Removed |Added CC||timothee.co...@gmail.com --- Comment #9 from Timothee Cour --- Faced this again, this is a serious bug that's 8 years old !! What are the difficulties involved in fixing this? For example, I see workarounds such as https://issues.dlang.org/show_bug.cgi?id=14301 which don't really address the root cause. Anything wrong with http://wiki.dlang.org/DIP22? --
[Issue 14610] [REG2.067] 'null this' assertion missing in 2.067
https://issues.dlang.org/show_bug.cgi?id=14610 --- Comment #3 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/fb10be8edcafbe4596b240b76fbbdf74cf2aafe8 fix Issue 14610 - [REG2.067] 'null this' assertion missing in 2.067 https://github.com/D-Programming-Language/dmd/commit/7dd1d175f8cdf12f8cec4646a4974c0e1187c137 Merge pull request #4678 from WalterBright/fix14610 fix Issue 14610 - [REG2.067] 'null this' assertion missing in 2.067 --
[Issue 14633] DDoc: false warnings for missing parameters on template declaration
https://issues.dlang.org/show_bug.cgi?id=14633 Lionello Lunesu changed: What|Removed |Added Assignee|nob...@puremagic.com|lio+bugzi...@lunesu.com --
[Issue 14633] DDoc: false warnings for missing parameters on template declaration
https://issues.dlang.org/show_bug.cgi?id=14633 --- Comment #1 from Lionello Lunesu --- https://github.com/D-Programming-Language/dmd/pull/4689 --
[Issue 14633] New: DDoc: false warnings for missing parameters on template declaration
https://issues.dlang.org/show_bug.cgi?id=14633
Issue ID: 14633
Summary: DDoc: false warnings for missing parameters on
template declaration
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: lio+bugzi...@lunesu.com
There are two cases where the ddoc compiler issues a warning for missing
parameters:
/** Blah
Params:
T = some type
test = something
*/
template case1(T)
{
void case1(R)(R test) { }
}
///ditto
alias case2 = case1!int;
In both cases `test` refers to the function parameter for the template function
`case1`. The ddoc compiler current looks for function parameters and template
parameters, but does not check the function parameters of a nested/eponymous
function template declaration.
--
[Issue 14567] [2.067] core.demangle: New Nk attribute not handled
https://issues.dlang.org/show_bug.cgi?id=14567 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kenji Hara --- PR was merged. --
[Issue 14566] [2.067] core.demangle: New Nj attribute not handled
https://issues.dlang.org/show_bug.cgi?id=14566 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Kenji Hara --- PR was merged. --
[Issue 14093] [REG2.065] __traits(compiles, cast(Object)(tuple)) is true even if it doesn't compile.
https://issues.dlang.org/show_bug.cgi?id=14093
--- Comment #7 from Kenji Hara ---
(In reply to Igor Stepanov from comment #6)
> This issue is not fully solved.
> There is simpler example:
> -
> struct FooBar
> {
> int a;
> int b;
> }
>
> void test14093()
> {
> FooBar foo;
> auto obj = cast(Object)foo; //e2ir: cannot cast foo of type FooBar to
> type object.Object
> }
> -
Will be fixed by:
https://github.com/D-Programming-Language/dmd/pull/4691
> Moreover, I think, this issue is solved incorrectly: alias this mechanism
> should reject `cast(Object)(point._tupleAliasThis_)` variant and continue
> process the root casting "cast(Object)point" excluding alias this.
> And result error message should be
> "Error: cannot cast expression point of type Tuple!(int, "x", int, "y") to
> object.Object".
> We are interested in subtyping (alias this, or inheritance) only when it can
> done its work (casting, .member ...).
It's rather diagnostic issue. I opened a new minor issue 14632.
--
[Issue 14629] Type system breaking and wrong code bugs in casting reference types to typeof(null)
https://issues.dlang.org/show_bug.cgi?id=14629 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4691 --
[Issue 14632] New: Diagnostic improvement for invalid cast with alias this
https://issues.dlang.org/show_bug.cgi?id=14632
Issue ID: 14632
Summary: Diagnostic improvement for invalid cast with alias
this
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Spin-off from issue 14093.
>From dmd test suite test/fail_compilation/fail_casting.d:
/*
TEST_OUTPUT:
---
fail_compilation/fail_casting.d(179): Error: cannot cast expression
__tup$n$.__expand_field_0 of type int to object.Object
fail_compilation/fail_casting.d(179): Error: cannot cast expression
__tup$n$.__expand_field_1 of type int to object.Object
---
*/
alias TypeTuple14093(T...) = T;
struct Tuple14093(T...)
{
static if (T.length == 4)
{
alias Types = TypeTuple14093!(T[0], T[2]);
Types expand;
@property ref inout(Tuple14093!Types) _Tuple_super() inout @trusted
{
return *cast(typeof(return)*) &(expand[0]);
}
alias _Tuple_super this;
}
else
{
alias Types = T;
Types expand;
alias expand this;
}
}
void test14093()
{
Tuple14093!(int, "x", int, "y") point;
auto newPoint = cast(Object)(point); // line 179
}
The message can be better as follows:
Error: cannot cast expression point of type Tuple14093!(int, "x", int, "y") to
object.Object
--
[Issue 14045] Redo the forums entry page and links
https://issues.dlang.org/show_bug.cgi?id=14045 Vladimir Panteleev changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #9 from Vladimir Panteleev --- Which forums should be kept on the index? C++ stuff - remove? DTL - remove? DWT - move up to "Ecosystem"? DMDScript - remove? digitalmars.empire - remove? There's also some stale mailing lists, or mailing lists only used for GitHub announcements (phobos, dmd-concurrency), keep/remove? CC Walter Bright --
