[Issue 18557] Types with 0 size should not be usable as aa key types
https://issues.dlang.org/show_bug.cgi?id=18557 --- Comment #2 from Walter Bright --- Spec: https://github.com/dlang/dlang.org/pull/2265 --
[Issue 18557] Types with 0 size should not be usable as aa key types
https://issues.dlang.org/show_bug.cgi?id=18557 --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/7986 --
[Issue 18559] std.math.* should stop using `real` overloads by default
https://issues.dlang.org/show_bug.cgi?id=18559 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from ki...@gmx.net --- (In reply to hsteoh from comment #0) > Let 80-bit be an option if the user > wants to, sure. But can we please, pretty please, change the default type > in std.math.* to double instead of real. Performing the operation in the precision of the operands is what I'd expect. So having to cast explicitly to real if my data is stored as float/double and max precision is needed. Some math functions are still only implemented for `real`, but they support reals in double/x87/quadruple precision for the different architectures, i.e., support for 64-bit doubles (proper constants, limits etc.) is already there. E.g., std.math.atan(real) could be generalized to a template (float/double/real) after adding single-precision support (from Cephes probably). --
[Issue 18559] New: std.math.* should stop using `real` overloads by default
https://issues.dlang.org/show_bug.cgi?id=18559 Issue ID: 18559 Summary: std.math.* should stop using `real` overloads by default Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: hst...@quickfur.ath.cx Using 80-bit reals on x86 causes major performance degradations in std.math functions like atan(). This poor performance is on the brink of turning away a significant group of potential D users, and needs to be taken seriously: Cf.: https://forum.dlang.org/post/aepfpjkytvpnzgizv...@forum.dlang.org It's about time we take off our blinders and stop pretending that 80-bit "extra" precision buys us anything. Let 80-bit be an option if the user wants to, sure. But can we please, pretty please, change the default type in std.math.* to double instead of real. This is making our "fast code fast" slogan look absolutely ridiculous when people run benchmarks like that linked to above, and see D performing horribly slow compared to C++. --
[Issue 13642] std.container.Array: change of length reallocates without notifying GC
https://issues.dlang.org/show_bug.cgi?id=13642 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/e837813478298593fdb2799e5af99b40a3ccb7b3 Fix issue 13642 - Change of length reallocates without notifying GC https://github.com/dlang/phobos/commit/997464b4b2a4a0af0fd6eeef1a9b3770c54762b9 Merge pull request #4885 from rjframe/arraymem Fix issue 13642 - Change of length reallocates without notifying GC merged-on-behalf-of: Jack Stouffer --
[Issue 13642] std.container.Array: change of length reallocates without notifying GC
https://issues.dlang.org/show_bug.cgi?id=13642 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18558] Template alias spec incomplete
https://issues.dlang.org/show_bug.cgi?id=18558
--- Comment #4 from Jonathan Marler ---
Maybe a better description...
template "alias" parameters can accept "symbols" and "values". If a symbol is
passed to the template, i.e.
MyTemplate!someSymbol
Then the symbol is passed directly to the template without being treated as an
expression to evaluate. Even if the symbol is a function, the function is not
called and then passed to the template, the function symbol is passed to it.
However, if an "non-symbol" expression is passed to the template, then the
expression is evaluated at "compile time" and the return value passed to it,
i.e.
MyTemplate!42
MyTemplate!(40 + 2)
enum x = 40;
MyTemplate!(x + 2)
auto return42() { return 42; }
MyTemplate!(return42())
All these represent the same template instantiation.
--
[Issue 18558] Template alias spec incomplete
https://issues.dlang.org/show_bug.cgi?id=18558
--- Comment #3 from Jonathan Marler ---
> No. At that point it's an alias of the function. It gets called inside `Foo`:
Ah I see you're right. If I add pragma(msg, typeof(x)) inside the template, it
shows that x is a function (not just a uint). If I change it to:
Foo!(return42())
Then x will actually be a uint.
Going a bit further, it looks like alias parameters do accept function calls,
but in that case the function call is evaluated outside the template, as
demonstrated by this example:
template Foo(alias x)
{
pragma(msg, typeof(x));
enum Foo = x;
}
int return42a() { return 42; }
int return42b() { return 42; }
void main()
{
auto foo1 = Foo!(return42a());
auto foo2 = Foo!(return42b());
auto foo3 = Foo!(42);
}
If you compile this, the template Foo only gets instantiated once meaning that
all 3 of these templates are the same.
Another interesting use case, it looks like you can also use expressions, i.e.
auto foo4 = Foo!(40 + 2);
--
[Issue 18558] Template alias spec incomplete
https://issues.dlang.org/show_bug.cgi?id=18558
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #2 from ag0ae...@gmail.com ---
(In reply to Jonathan Marler from comment #1)
> Based on the example in the comment above, the following:
>
> Foo!return42
>
> treats the `return42` part as a function call with no arguments instead of
> passing the `return42` symbol to the Foo template. Note that this is still
> true even if return42 takes arguments, it will treat it as an erroneous
> function call.
No. At that point it's an alias of the function. It gets called inside `Foo`:
template Foo(alias x)
{
enum Foo = x; /* This calls x. */
}
--
[Issue 18558] Template alias spec incomplete
https://issues.dlang.org/show_bug.cgi?id=18558 --- Comment #1 from Jonathan Marler --- Quick clarification. Based on the example in the comment above, the following: Foo!return42 treats the `return42` part as a function call with no arguments instead of passing the `return42` symbol to the Foo template. Note that this is still true even if return42 takes arguments, it will treat it as an erroneous function call. --
[Issue 18558] New: Template alias spec incomplete
https://issues.dlang.org/show_bug.cgi?id=18558
Issue ID: 18558
Summary: Template alias spec incomplete
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: johnnymar...@gmail.com
https://dlang.org/spec/template.html#TemplateAliasParameter
[Copied from spec]
Alias parameters enable templates to be parameterized with almost any kind of D
symbol, including user-defined type names, global names, local names, module
names, template names, and template instance names. Literals can also be used
as arguments to alias parameters.
I've found that you can also pass function calls, i.e.
template Foo(alias x)
{
enum Foo = x;
}
size_t return42() { return 42; }
void main()
{
auto foo2 = Foo!(return42());
pragma(msg, typeof(foo2).stringof);
}
The spec should be updated to describe the true capabilities of alias template
parameters. It sounds like along with symbols and literals, alias parameters
can also accept compile-time values.
--
[Issue 18548] [2.079] std.format ignores templated toString if another toString is not a template
https://issues.dlang.org/show_bug.cgi?id=18548 Jack Stouffer changed: What|Removed |Added Summary|[2.079 Beta] std.format |[2.079] std.format ignores |ignores templated toString |templated toString if |if another toString is not |another toString is not a |a template |template --
[Issue 18551] Improve hint for "does not override any function
https://issues.dlang.org/show_bug.cgi?id=18551 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- PR : https://github.com/dlang/dmd/pull/7984 --
[Issue 18557] New: Types with 0 size should not be usable as aa key types
https://issues.dlang.org/show_bug.cgi?id=18557
Issue ID: 18557
Summary: Types with 0 size should not be usable as aa key types
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
Summary says it all.
struct S { }
int[S] aa; // should fail to compile
--
