[Issue 24176] New: Parameters of opApply delegate don't have to be `ref`
https://issues.dlang.org/show_bug.cgi?id=24176 Issue ID: 24176 Summary: Parameters of opApply delegate don't have to be `ref` Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: n...@geany.org The spec should be clearer on that. Also a `ref` parameter of the delegate can accept non-ref foreach variables. PR incoming. --
[Issue 24176] Parameters of opApply delegate don't have to be `ref`
https://issues.dlang.org/show_bug.cgi?id=24176 Nick Treleaven changed: What|Removed |Added Keywords||spec --
[Issue 24176] Parameters of opApply delegate don't have to be `ref`
https://issues.dlang.org/show_bug.cgi?id=24176 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3699 "[spec] Improve `opApply` docs" fixing this issue: - [spec] Improve `opApply` docs Show grammar for signature. Don't require `ref` delegate parameter. Explain non-ref ForeachType can match a ref OpApplyParameter. Fixes Issue 24176 - Parameters of opApply delegate don't have to be `ref`. https://github.com/dlang/dlang.org/pull/3699 --
[Issue 11936] Allow non-`ref` parameters in `foreach` over range `delegate`/`opApply`
https://issues.dlang.org/show_bug.cgi?id=11936
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #1 from Nick Treleaven ---
Still fails:
foreach (a; dg1) {}
foreachdelegate.d(6): Error: delegate `dg1(int delegate(int))` is not callable
using argument types `(int delegate(ref int __applyArg0) pure nothrow @nogc
@safe)`
foreachdelegate.d(6):cannot pass argument `__foreachbody3` of type `int
delegate(ref int __applyArg0) pure nothrow @nogc @safe` to parameter `int
delegate(int)`
However, this works:
int f(int delegate(int));
foreach (a; &f) {}
--
[Issue 5445] DMD does not look for ".dmd.conf" in HOME dir
https://issues.dlang.org/show_bug.cgi?id=5445 Dlang Bot changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dmd pull request #15648 "Fix issue 5445 - DMD does not look for ".dmd.conf" in HOME dir" was merged into master: - 63a60563147c0c3f859b8563a4a4b2485226658f by Mai-Lapyst: Fix issue 5445 - DMD does not look for ".dmd.conf" in HOME dir https://github.com/dlang/dmd/pull/15648 --
[Issue 24177] New: Array literal can implicitly convert to an expected type
https://issues.dlang.org/show_bug.cgi?id=24177 Issue ID: 24177 Summary: Array literal can implicitly convert to an expected type Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: n...@geany.org The spec should state that an array literal can implicitly convert each of its elements when there is an expected array type available. (This is much safer than casting the literal). PR incoming. --
[Issue 24177] Array literal can implicitly convert to an expected type
https://issues.dlang.org/show_bug.cgi?id=24177 Nick Treleaven changed: What|Removed |Added Keywords||spec --
[Issue 24177] Array literal can implicitly convert to an expected type
https://issues.dlang.org/show_bug.cgi?id=24177 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3701 "[spec] Array literal can implicitly convert to an expected type" fixing this issue: - [spec] Array literal can implicitly convert to an expected type Fix Issue 24177 - Array literal can implicitly convert to an expected type. Use this feature to avoid casting elements manually in example. https://github.com/dlang/dlang.org/pull/3701 --
[Issue 16357] cast(T[])[x] casts x to T instead of [x] to T[]
https://issues.dlang.org/show_bug.cgi?id=16357 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @ntrel updated dlang/dlang.org pull request #3701 "[spec] Array literal can implicitly convert to an expected type" fixing this issue: - Show overflow in example Fix Issue 16357 - cast(T[])[x] casts x to T instead of [x] to T[]. https://github.com/dlang/dlang.org/pull/3701 --
[Issue 16357] cast(T[])[x] casts x to T instead of [x] to T[]
https://issues.dlang.org/show_bug.cgi?id=16357 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #5 from Nick Treleaven --- I've made a PR to update the spec. I don't think we can make that an error without risking existing code breakage. --
[Issue 24175] DIP1000 fails to determine proper lifetime for struct
https://issues.dlang.org/show_bug.cgi?id=24175 --- Comment #2 from Grim Maple --- I don't understand how this is invalid, when the code I wrote is completely valid, doesn't escape references, yet is marked as "escaping references" --
[Issue 24175] DIP1000 fails to determine proper lifetime for struct
https://issues.dlang.org/show_bug.cgi?id=24175
Max Samukha changed:
What|Removed |Added
CC||maxsamu...@gmail.com
--- Comment #3 from Max Samukha ---
(In reply to Grim Maple from comment #2)
> I don't understand how this is invalid, when the code I wrote is completely
> valid, doesn't escape references, yet is marked as "escaping references"
The problem is separate compilation/lack of lifetime inference:
struct A
{
this(int[] data) @safe;
int[] a;
}
Now, compiler doesn't know whether the constructor stores the argument in a
location outliving 'this'. People are busy trying to be compatible with
stone-age technologies, so it's unlikely to change.
--
[Issue 24173] ImportC: add Microsoft iNN integer literal suffixes
https://issues.dlang.org/show_bug.cgi?id=24173 Walter Bright changed: What|Removed |Added Summary|ImportC: unable to parse|ImportC: add Microsoft iNN |microsoft extended integer |integer literal suffixes |literals| Severity|normal |enhancement --
[Issue 24173] ImportC: add Microsoft iNN integer literal suffixes
https://issues.dlang.org/show_bug.cgi?id=24173 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @WalterBright created dlang/dmd pull request #15654 "fix Issue 24173 - ImportC: add Microsoft iNN integer literal suffixes" fixing this issue: - fix Issue 24173 - ImportC: add Microsoft iNN integer literal suffixes https://github.com/dlang/dmd/pull/15654 --
[Issue 24175] DIP1000 fails to determine proper lifetime for struct
https://issues.dlang.org/show_bug.cgi?id=24175
apham changed:
What|Removed |Added
CC||ap...@hotmail.com
--- Comment #4 from apham ---
SCOPE & dip1000 is not for prime-time yet. Still having bug & not easier to use
as below sample
@safe:
class C1
{
@safe:
int i;
}
struct A1
{
@safe:
this(C1 c1, return scope int[] a)
{
this.a = a;
this.c1 = c1;
this.c1s.reserve(10);
}
C1 compute()
{
return c1;
}
int[] a;
C1[] c1s;
C1 c1;
}
int main()
{
int n;
{ // Simulate a scope block
C1 c1 = new C1();
int[3] a = [1, 2, 3];
A1 a1 = A1(c1, a[]);
n = a1.compute().i;
}
return n;
}
onlineapp.d(18): Error: scope variable `this` assigned to non-scope parameter
`arr` calling `reserve`
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3931):which
is not `scope` because of `cast(void[]*)&arr`
onlineapp.d(38): Error: scope variable `a1` calling non-scope member function
`A1.compute()`
--
[Issue 11070] Allow declaration statement in a switch expression
https://issues.dlang.org/show_bug.cgi?id=11070 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #12 from Dlang Bot --- @Mai-Lapyst created dlang/dmd pull request #15656 "Fix issue 11070 - Allow declaration statement in a switch expression" fixing this issue: - Fix issue 11070 - Allow declaration statement in a switch expression https://github.com/dlang/dmd/pull/15656 --
[Issue 24173] ImportC: add Microsoft iNN integer literal suffixes
https://issues.dlang.org/show_bug.cgi?id=24173 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15654 "fix Issue 24173 - ImportC: add Microsoft iNN integer literal suffixes" was merged into master: - 6bf842e290dba4624dcb5e4dafdae5a0f2aa2ce7 by Walter Bright: fix Issue 24173 - ImportC: add Microsoft iNN integer literal suffixes https://github.com/dlang/dmd/pull/15654 --
