[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097
--- Comment #15 from Mike Franklin ---
I think in my prior example, I may have overlooked the implicit `this` argument
for member functions. Here I attempt to compensate.
//
// OK, only one possible *output*
int* f(return scope int* p);
// OK, only one possible *output*
void f(ref scope int* r, return scope int* p);
//
// Error: `return` must be disambiguated between `this` and `r`
void f(ref scope int* r1, ref scope int* r2, return scope int* p);
// OK, `return` has been disambiguated
void f(ref scope int* r1, ref scope int* r2, return(r1) scope int* p);
void f(ref scope int* r1, ref scope int* r2, return(r2) scope int* p);
//
// Error: `return` must be disambiguated between the return value
// and the `r` output parameter.
int* f(ref scope int* r, return scope int* p);
// OK, `return` has been disambiguated
int* f(ref scope int* r, return(r) scope int* p);
// OK, `return` has been disambiguated
// `return(return)` is pretty yucky, but I can't think of anything
// else right now.
int* f(ref scope int* r, return(return) scope int* p);
struct S
{
// Error: `return` must be disambiguated between `this` and `r`
this(ref scope int* r, return scope int* p);
// OK, `return` has been disambiguated
this(ref scope int* r, return(this) scope int* p);
this(ref scope int* r, return(r) scope int* p);
//
// Error: `return` must be disambiguated between `this` and `r`
void f(ref scope int* r, return scope int* p);
// OK, `return` has been disambiguated
void f(ref scope int* r, return(this) scope int* p);
// OK, `return` has been disambiguated
void f(ref scope int* r, return(r) scope int* p);
//
// Error: `return` must be disambiguated between `this`, `r1`, and `r2`
void f(ref scope int* r1, ref scope int* r2, return scope int* p);
// OK, `return` has been disambiguated
void f(ref scope int* r1, ref scope int* r2, return(r1) scope int* p);
void f(ref scope int* r1, ref scope int* r2, return(r2) scope int* p);
//
// Error: `return` must be disambiguated between `this` and the return
value
int* f(return scope int* p);
// OK, `return` has been disambiguated
int* f(return(this) scope int* p);
// OK, `return` has been disambiguated - tied to return value
int* f(return(return) scope int* p);
}
Hopefully, you get the idea.
--
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097
--- Comment #14 from Mike Franklin ---
Here's a little more about what I'm thinking:
struct S
{
// Error: `return` must be disambiguated between `this` and `r`
this(ref scope int* r, return scope int* p);
// OK, `return` has been disambiguated
this(ref scope int* r, return(this) scope int* p);
this(ref scope int* r, return(r) scope int* p);
// OK, only one possible *output*
int* f(return scope int* p);
// OK, only one possible *output*
void f(ref scope int* r, return scope int* p);
// Error: `return` must be disambiguated between `this` and `r`
void f(ref scope int* r1, ref scope int* r2, return scope int* p);
// OK, `return` has been disambiguated
void f(ref scope int* r1, ref scope int* r2, return(r1) scope int* p);
void f(ref scope int* r1, ref scope int* r2, return(r2) scope int* p);
// Error: `return` must be disambiguated between the return value
// and the `r` output parameter.
int* f(ref scope int* r, return scope int* p);
// OK, `return` has been disambiguated
int* f(ref scope int* r, return(r) scope int* p);
// OK, `return` has been disambiguated
// `return(return)` is pretty yucky, but I can't think of anything
// else right now.
int* f(ref scope int* r, return(return) scope int* p);
}
--
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097
--- Comment #13 from Mike Franklin ---
For constructors, one could use `return(this)` to the same effect. Perhaps for
constructors, if there are no other "output" parameters in the signature,
`return(this)` could be inferred by simply typing add `return` to the input
parameters. If there is more than one "output" parameter, the user would have
to explicitly disambiguate by adding an argument to the `return` attribute.
struct S
{
// does `return` apply to `this` or `r`?
this(ref scope int* r, return scope int* p);
// disambiguate by explicitly adding an argument to `return`
this(ref scope int* r, return(this) scope int* p);
// or
this(ref scope int* r, return(r) scope int* p);
}
--
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097
--- Comment #12 from Mike Franklin ---
I'm wondering if it might be possible to do something like this:
```
void betty(ref scope int* r, return(r) scope int* p)
{
r = p;
}
```
`return(r)` explicitly ties p's lifetime to r's.
So, the `return` attribute would take an argument specifying which "output"
parameter to tie the input lifetime to, and the semantics no longer rely on
convention or the order of arguments.
--
[Issue 19458] New: Speculatively-instantiated templates may give incorrect results
https://issues.dlang.org/show_bug.cgi?id=19458
Issue ID: 19458
Summary: Speculatively-instantiated templates may give
incorrect results
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: snarwin+bugzi...@gmail.com
Example program:
--- test.d
struct A
{
static if (__traits(compiles, hasFoo!A)) {
void foo() {}
}
}
enum hasFoo(T) = __traits(hasMember, T, "foo");
void main()
{
import std.stdio;
writeln(hasFoo!A); // false (should be true)
writeln(__traits(hasMember, A, "foo")); // true
}
---
Output:
$ dmd test.d && ./test
false
true
When `hasFoo!A` is instantiated in the `__traits(compiles)` expression, it
evaluates to false, because the body of the `static if` statement has not been
compiled yet. The same instantiation is then re-used in `main`, even though it
is no longer semantically correct.
Possibly related to issue 14803.
--
[Issue 19457] New: Clarify dmd requirements for FreeBSD
https://issues.dlang.org/show_bug.cgi?id=19457 Issue ID: 19457 Summary: Clarify dmd requirements for FreeBSD Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: andrew.penneba...@gmail.com The dub package manager is unable to reach the dlang repository without libcurl.so installed, so it would be good to mention that curl should be installed, along with gcc, in order to be able to use important dlang features. --
[Issue 19456] New: ParameterIdentifierTuple incorrect for abstract methods with unnamed parameters
https://issues.dlang.org/show_bug.cgi?id=19456
Issue ID: 19456
Summary: ParameterIdentifierTuple incorrect for abstract
methods with unnamed parameters
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: johnch_a...@hotmail.com
ParameterIdentifierTuple returns incorrect results for abstract methods on
classes and interfaces.
class SomeClass {
abstract void first(SomeClass);
abstract void second(int);
void third(SomeClass) {}
}
pragma(msg, ParameterIdentifierTuple!(__traits(getMember, SomeClass, "first"));
// outputs: tuple("SomeClass")
pragma(msg, ParameterIdentifierTuple!(__traits(getMember, SomeClass,
"second")); // outputs: tuple("")
pragma(msg, ParameterIdentifierTuple!(__traits(getMember, SomeClass, "third"));
// outputs: tuple("_param_0")
ParameterIdentifierTuple uses __traits(identifier,...) under the hood, and it
looks like that's ultimately where the issue is. ParameterIdentifierTuple on
non-abstract methods always seems to produce "_param_0", "_param_1" and so on.
However, I'd expect to see a tuple of empty strings in all three cases.
--
[Issue 19455] GC wastes too much memory
https://issues.dlang.org/show_bug.cgi?id=19455 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #1 from Rainer Schuetze --- https://github.com/dlang/druntime/pull/2384 --
[Issue 19455] New: GC wastes too much memory
https://issues.dlang.org/show_bug.cgi?id=19455
Issue ID: 19455
Summary: GC wastes too much memory
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
The GC allocates in chunks that are a power of 2. This causes a lot of memory
wasted:
module waste;
import core.memory;
struct S
{
char[129] data;
}
void main()
{
GC.disable();
foreach (_; 0 .. 100)
new S;
}
compile and run with
>waste.exe --DRT-gcopt=profile:1
Number of collections: 2
Total GC prep time: 0 milliseconds
Total mark time: 0 milliseconds
Total sweep time: 8 milliseconds
Total page recovery time: 3 milliseconds
Max Pause Time: 0 milliseconds
Grand total GC time: 12 milliseconds
GC summary: 247 MB,2 GC 12 ms, Pauses0 ms <0 ms
=> even though only 129 MB are allocated, the GC needs 247 MB. With a struct
size of 128, it needs 145 MB.
--
[Issue 19454] Name collisions with unnamed function parameters
https://issues.dlang.org/show_bug.cgi?id=19454 Seb changed: What|Removed |Added CC||greeen...@gmail.com Severity|enhancement |major --
[Issue 19454] New: Name collisions with unnamed function parameters
https://issues.dlang.org/show_bug.cgi?id=19454
Issue ID: 19454
Summary: Name collisions with unnamed function parameters
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dhase...@gmail.com
Example:
---
void foo(int _param_1, int) {}
---
Result is a compile error:
Error: function `scratch.foo` parameter foo._param_1 is already defined
Double-underscore identifiers are reserved by the compiler, but other
identifiers are not. The fix is to change _param_[index] to __param_[index],
presumably. That won't change the name collision, but it will at least move it
to "here be dragons" territory instead of "this looks like it should work".
--
[Issue 1983] Delegates violate const
https://issues.dlang.org/show_bug.cgi?id=1983
--- Comment #23 from anonymous4 ---
f(()const{}); works, but doesn't enforce const for closure.
--
[Issue 15801] Enum template with alias parameter overload not considered
https://issues.dlang.org/show_bug.cgi?id=15801 Nick Treleaven changed: What|Removed |Added Keywords||rejects-valid Summary|Enum alias parameter|Enum template with alias |variable cannot be read at |parameter overload not |compile-time|considered --
[Issue 14359] [SDC] Allow inferring template parameter from type of template value parameter
https://issues.dlang.org/show_bug.cgi?id=14359 Nick Treleaven changed: What|Removed |Added CC||yshu...@gmail.com --- Comment #4 from Nick Treleaven --- *** Issue 17279 has been marked as a duplicate of this issue. *** --
[Issue 17279] Deduce type from value parameter as well
https://issues.dlang.org/show_bug.cgi?id=17279 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |DUPLICATE --- Comment #1 from Nick Treleaven --- *** This issue has been marked as a duplicate of issue 14359 *** --
[Issue 19214] Support object.destruct() for efficient (and correct!) destruction
https://issues.dlang.org/show_bug.cgi?id=19214 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/0fe98729034a2d7bc76bfc81c25e9dbd1f3d560a Fixes Issue 19214 - Support object.destruct() for efficient (and correct!) destruction --
[Issue 19214] Support object.destruct() for efficient (and correct!) destruction
https://issues.dlang.org/show_bug.cgi?id=19214 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19442] Issues with multiple argument string mixin
https://issues.dlang.org/show_bug.cgi?id=19442 Nick Treleaven changed: What|Removed |Added Keywords||rejects-valid URL||https://dlang.org/spec/expr ||ession.html#MixinExpression Severity|enhancement |minor --
[Issue 1983] Delegates violate const
https://issues.dlang.org/show_bug.cgi?id=1983
Simen Kjaeraas changed:
What|Removed |Added
CC||simen.kja...@gmail.com
--- Comment #22 from Simen Kjaeraas ---
(In reply to anonymous4 from comment #21)
> void f(void delegate() const a);
> unittest
> {
> A a;
> f();
> }
Sadly, this also disallows a large set of valid use cases, the simplest of
which is f((){}).
If (){} yielded a void delegate() const, this would not be a problem.
--
[Issue 19453] Remove unnecessary error checks in std.datetime.systime.currStdTime()
https://issues.dlang.org/show_bug.cgi?id=19453 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/phobos/pull/6785 --
[Issue 19453] New: Remove unnecessary error checks in std.datetime.systime.currStdTime()
https://issues.dlang.org/show_bug.cgi?id=19453 Issue ID: 19453 Summary: Remove unnecessary error checks in std.datetime.systime.currStdTime() Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com As in https://issues.dlang.org/show_bug.cgi?id=19280 for druntime. --
[Issue 19280] Remove unnecessary error checks in core.time.currSystemTick and currTime
https://issues.dlang.org/show_bug.cgi?id=19280 Nathan S. changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=19453 --
[Issue 18630] std.math must CTFE
https://issues.dlang.org/show_bug.cgi?id=18630 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #3 from Simen Kjaeraas --- (In reply to Eduard Staniloiu from comment #2) > Maybe you can replace the static ctor with this idiom > https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through- > CTFE That's exactly what he's trying to do. In 2.083.0, the following functions in std.math are still not CTFE-able: nextPow2 truncPow2 asin atan2 expi lround lrint rndtol quantize frexp ilogb scalbn Getting there, though - in 2.081.1, the list was about twice as big. --
