[Issue 11904] Error: this cannot be interpreted at compile-time (core/time.di)
https://issues.dlang.org/show_bug.cgi?id=11904 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |INVALID --- Comment #2 from Mathias LANG --- Looks like this bug is quite outdated, and actually relates to GDC. I'm going to close this since the issue itself seems resolved. If you have another report which is GDC-related, please direct it to https://bugzilla.gdcproject.org/ --
[Issue 5749] (D1 only) argument evaluation order of chained function from right
https://issues.dlang.org/show_bug.cgi?id=5749 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WORKSFORME --- Comment #11 from Mathias LANG --- > Fixed in D2. And so, finally closing this. --
[Issue 1861] (D1 only) .sort fails if opCmp takes a ref param
https://issues.dlang.org/show_bug.cgi?id=1861 Mathias LANG changed: What|Removed |Added Status|REOPENED|RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WORKSFORME --- Comment #6 from Mathias LANG --- D2 builtin sort is gone, closing. --
[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf
https://issues.dlang.org/show_bug.cgi?id=19197 Nathan S. changed: What|Removed |Added CC||n8sh.second...@hotmail.com --- Comment #2 from Nathan S. --- >Is the return of the hashOf different that the one for the one for >the typeid(T).getHash(..)? It can be. https://dlang.org/phobos/object.html#.hashOf >Calculates the hash value of `arg` with an optional `seed` initial >value. The result might not be equal to `typeid(T).getHash()`. --
[Issue 4485] CT only arrays appear in executable
https://issues.dlang.org/show_bug.cgi?id=4485 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |INVALID --- Comment #2 from Mathias LANG --- Indeed, this is the correct behavior. `static immutable` + initializer, or `static const` + initializer leads to a manifest constant which is an lvalue (you can take the address of it). On the other hand, `enum` leads to an rvalue (much like a define, it is copy pasted everywhere). Closing as INVALID. --
[Issue 19321] Unions "may not" have fields with destructors
https://issues.dlang.org/show_bug.cgi?id=19321 --- Comment #2 from Stanislav Blinov --- I propose to still make the change, but also add a note about outstanding bugs (IIRC there was another one concerning assignment of fields). At least that way the spec will not be misleading. --
[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf
https://issues.dlang.org/show_bug.cgi?id=19197 --- Comment #1 from Tiberiu Lepadatu --- (In reply to ZombineDev from comment #0) > Since core.internal.hash.hashOf is a template, there are a number potential > benefits: > * better performance (e.g. more opportunities for inlining, less > indirections for value types) > * less dependence on TypeInfo (which we want to phase out in the long term) > * -betterC friendly (no need to link druntime and phobos to your library / > app, in order to use simple templates like std.typecons.Nullable) I have started working on this but when I change typeid(T).getHash(..) to hashOf at line 2682 the unittest is failing. Is the return of the hashOf different that the one for the one for the typeid(T).getHash(..)? --
[Issue 19264] byCodeUnit should compare with strings
https://issues.dlang.org/show_bug.cgi?id=19264 dcua...@yahoo.com changed: What|Removed |Added CC||dcua...@yahoo.com Assignee|nob...@puremagic.com|dcua...@yahoo.com --
[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf
https://issues.dlang.org/show_bug.cgi?id=19197 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com Assignee|nob...@puremagic.com|tiberiulepadat...@gmail.com --
[Issue 19283] [std.mathspecial] documentation for normal distribution doesn't list parameters
https://issues.dlang.org/show_bug.cgi?id=19283 dcua...@yahoo.com changed: What|Removed |Added CC||dcua...@yahoo.com Assignee|nob...@puremagic.com|dcua...@yahoo.com --
[Issue 6106] Keep track of changes during replace function
https://issues.dlang.org/show_bug.cgi?id=6106 dcua...@yahoo.com changed: What|Removed |Added CC||dcua...@yahoo.com Assignee|nob...@puremagic.com|dcua...@yahoo.com --
[Issue 19323] New: Pure function nesting explanation; move to correct spot in specs
https://issues.dlang.org/show_bug.cgi?id=19323 Issue ID: 19323 Summary: Pure function nesting explanation; move to correct spot in specs Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: trivial Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: aras...@protonmail.com https://dlang.org/spec/function.html#inout-functions Within 19.10 (Inout Functions), point 9 states: Nested functions inside pure function are implicitly marked as pure. This should be either under 19.5 (Pure Functions) or 19.18 (Nested Functions). I suggest the latter. --
[Issue 18728] std.math.fdim does not handle nan correctly
https://issues.dlang.org/show_bug.cgi?id=18728 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #1 from Tiberiu Lepadatu --- Can I work on this? --
[Issue 19316] GC runtime breaks @safe
https://issues.dlang.org/show_bug.cgi?id=19316 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED CC||simen.kja...@gmail.com Resolution|--- |INVALID --- Comment #1 from Simen Kjaeraas --- Can you demonstrate how this actually causes problems? No data is being passed from @safe to @system, so nothing actually un-@safe will happen due to this. --
[Issue 19264] byCodeUnit should compare with strings
https://issues.dlang.org/show_bug.cgi?id=19264 Eduard Staniloiu changed: What|Removed |Added Keywords||bootcamp CC||edi33...@gmail.com --
[Issue 19283] [std.mathspecial] documentation for normal distribution doesn't list parameters
https://issues.dlang.org/show_bug.cgi?id=19283 Eduard Staniloiu changed: What|Removed |Added Keywords||bootcamp CC||edi33...@gmail.com --
[Issue 19321] Unions "may not" have fields with destructors
https://issues.dlang.org/show_bug.cgi?id=19321 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #1 from Simen Kjaeraas --- Definitely not excised - the fact that union member destructors should not be called by the compiler is not immediately obvious, and the user should be warned of this fact. Also, the text should probably advocate destroy(u.field) over calling __xdtor directly. Otherwise, your text looks good. One related problem is issue 19122, or the fact that destructors are indeed being called automatically for union members. That shouldn't affect this issue, but it means that your text isn't correct until 19122 is fixed. --
[Issue 18998] Improve Operator Overloading docs
https://issues.dlang.org/show_bug.cgi?id=18998 Cristian Creteanu changed: What|Removed |Added CC||cristiancretean...@gmail.co ||m Assignee|nob...@puremagic.com|cristiancretean...@gmail.co ||m --
[Issue 19294] Support for array operations with Complex! is incomplete
https://issues.dlang.org/show_bug.cgi?id=19294 Cristian Creteanu changed: What|Removed |Added CC||cristiancretean...@gmail.co ||m Assignee|nob...@puremagic.com|cristiancretean...@gmail.co ||m --
[Issue 18290] std.conv.parse throws ConvOverflowException for negative values in hex
https://issues.dlang.org/show_bug.cgi?id=18290 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #1 from Tiberiu Lepadatu --- (In reply to Răzvan Ștefănescu from comment #0) > string input = "8000"; > auto x = parse!int(input, 16); > //ConvOverflowException I feel that this is not a bug. To show that you are using a hex string you must use "0x" in front. If you write "0x8000" instead of "8000" there is no bug. --
[Issue 19294] Support for array operations with Complex! is incomplete
https://issues.dlang.org/show_bug.cgi?id=19294 Eduard Staniloiu changed: What|Removed |Added Keywords||bootcamp CC||edi33...@gmail.com --
[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf
https://issues.dlang.org/show_bug.cgi?id=19197 Eduard Staniloiu changed: What|Removed |Added Keywords||bootcamp CC||edi33...@gmail.com --
[Issue 19324] New: Code ")<" does not respect the coding
https://issues.dlang.org/show_bug.cgi?id=19324 Issue ID: 19324 Summary: Code ")<" does not respect the coding Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: dcua...@yahoo.com In std.internal.math.errorfunction we have comparison : function()< x instead of funtion() < x --
[Issue 8025] std.net.curl.del should return response body.
https://issues.dlang.org/show_bug.cgi?id=8025 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com Assignee|nob...@puremagic.com|tiberiulepadat...@gmail.com --
[Issue 3129] Cannot take advantage of overriding Throwable.toString
https://issues.dlang.org/show_bug.cgi?id=3129 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #2 from Tiberiu Lepadatu --- Bug not reproducible. --
[Issue 18499] std.regex cannot handle (?i:)
https://issues.dlang.org/show_bug.cgi?id=18499 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #1 from Tiberiu Lepadatu --- Even if this is not a bug rather a feature that is not supported in the regex library, I think that the error output should write that ":" is not allowed after "?i". --
[Issue 18571] Missing functions in std.complex
https://issues.dlang.org/show_bug.cgi?id=18571 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #3 from Tiberiu Lepadatu --- Is the formula "ln(z) = ln|z| + i * (Arg(z))" enough for a naive implementation? --
[Issue 19316] GC runtime breaks @safe
https://issues.dlang.org/show_bug.cgi?id=19316
Stanislav Blinov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #2 from Stanislav Blinov ---
It is being passed: C may define static data accessible to 'safeFunc'.
The point is, this includes any arbitrary un-@safe code, e.g. catching an Error
or even a Throwable. Net effect is that this code:
static C c;
void safeFunc() @safe {
destroy(c);
}
would fail to compile, and yet that same code executes via GC.
There's another unfortunate consequence of this behavior: 'pure' is also
affected, as is nothrow (though the latter terminates the program anyway as it
results in a FinalizationError).
--
[Issue 19316] GC runtime breaks @safe
https://issues.dlang.org/show_bug.cgi?id=19316 ag0aep6g changed: What|Removed |Added Keywords||safe CC||ag0ae...@gmail.com --
[Issue 18464] fullyQualifiedName!ifloat and fullyQualifiedName!cfloat fail
https://issues.dlang.org/show_bug.cgi?id=18464 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #3 from Tiberiu Lepadatu --- I think that the error comes from the fact that fqnType does not recognize c and i types. Should I write a fix, giving the fact that the types will be eliminated? --
[Issue 18467] std.format: Hangul Jamo syllables, while correctly segmented as single graphemes by graphemeStride, are designated as wide characters, and thus should occupy 2 spaces per grapheme
https://issues.dlang.org/show_bug.cgi?id=18467 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #1 from Tiberiu Lepadatu --- Shouldn't this be closed? --
[Issue 18448] Make std.file.write / std.stdio.write conflicts more tractable for beginners
https://issues.dlang.org/show_bug.cgi?id=18448 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #1 from Tiberiu Lepadatu --- Can you please suggest a solution? The current error message seems self explanatory to me std.stdio.write!(string, string).write at ~/dlang/dmd/generated/linux/release/64/../../../../../phobos/std/stdio.d(3729) conflicts with std.file.write!string.write at ~/dlang/dmd/generated/linux/release/64/../../../../../phobos/std/file.d(735) --
[Issue 18448] Make std.file.write / std.stdio.write conflicts more tractable for beginners
https://issues.dlang.org/show_bug.cgi?id=18448 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #2 from Seb --- 1) deprecate 2) improve the error message 3) improve the documentation --
[Issue 17647] Fedora/CentOS RPM x86_64 depends on i686 libraries
https://issues.dlang.org/show_bug.cgi?id=17647 leeavi...@gmail.com changed: What|Removed |Added CC||leeavi...@gmail.com --- Comment #1 from leeavi...@gmail.com --- I was able to create an RPM that installed ok on my laptop running fedora 28 (64 bit) by getting rid of the highlighted lines at https://github.com/dlang/installer/blob/235faa9a786858718f9d7937decbd0bc5b96a46c/linux/dmd_rpm.sh#L272-L278 It looks like the 64 bit RPMs intentionally depend on both 32 and 64 bit libcurl, and libgcc, though I can't imagine why (I'm an RPM noob.) --
[Issue 19325] New: The 'body' keyword is still not deprecated
https://issues.dlang.org/show_bug.cgi?id=19325
Issue ID: 19325
Summary: The 'body' keyword is still not deprecated
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
As per DIP 1003
(https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1003.md), the below
should have emitted a deprecation:
-
void main ( )
{
}
void test ()
in
{ }
body
{ }
-
The deprecation is not yet listed on dlang.org as well:
https://dlang.org/deprecate.html
--
Minor issue since we can already use 'body' thank to how the DIP was
implemented.
--
