On Wednesday, 5 June 2024 at 18:31:12 UTC, Basile B. wrote:
On Wednesday, 5 June 2024 at 01:18:06 UTC, Paul Backus wrote:
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
```d
void main(string[] args)
{
ushort a = 0b;
bool* b = cast(bool*)
setIt(*b);
On Wednesday, 5 June 2024 at 01:18:06 UTC, Paul Backus wrote:
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
```d
void main(string[] args)
{
ushort a = 0b;
bool* b = cast(bool*)
setIt(*b);
assert(a == 0b); // what actually happens
On Wednesday, 5 June 2024 at 09:09:40 UTC, Kagamin wrote:
On Wednesday, 5 June 2024 at 01:18:06 UTC, Paul Backus wrote:
The only safe values for a `bool` are 0 (false) and 1 (true).
AFAIK that was fixed and now full 8-bit range is safe.
`cast(bool) someByte` is fine - that doesn't
On Wednesday, 5 June 2024 at 01:18:06 UTC, Paul Backus wrote:
The only safe values for a `bool` are 0 (false) and 1 (true).
AFAIK that was fixed and now full 8-bit range is safe.
Basile B. kirjoitti 4.6.2024 klo 19.58:
I understand that the notion of `bool` doesn't exist on X86, hence what
will be used is rather an instruction that write on the lower 8 bits,
but with a 7 bits corruption.
Do I corrupt memory here or not ?
Is that a safety violation ?
Viewing a valid
On Wednesday, 5 June 2024 at 05:15:42 UTC, Olivier Pisano wrote:
This is technically not a memory corruption, because as
bool.sizeof < int.sizeof, you just write the low order byte of
an int you allocated on the stack.
It was not an int, it was a ushort. Anyway, what I wrote still
applies.
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
question in the header, code in the body, execute on a X86 or
X86_64 CPU
I understand that the notion of `bool` doesn't exist on X86,
hence what will be used is rather an instruction that write on
the lower 8 bits, but with a 7 bits
On Wednesday, 5 June 2024 at 01:18:06 UTC, Paul Backus wrote:
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
you have violated the language's safety invariants.
ah mais non.
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
```d
void main(string[] args)
{
ushort a = 0b;
bool* b = cast(bool*)
setIt(*b);
assert(a == 0b); // what actually happens
assert(a == 0b1110); // what would be safe
}
```
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
question in the header, code in the body, execute on a X86 or
X86_64 CPU
```d
module test;
void setIt(ref bool b) @safe
{
b = false;
}
void main(string[] args)
{
ushort a = 0b;
bool* b = cast(bool
On Tuesday, 4 June 2024 at 16:58:50 UTC, Basile B. wrote:
question in the header, code in the body, execute on a X86 or
X86_64 CPU
```d
module test;
void setIt(ref bool b) @safe
{
b = false;
}
void main(string[] args)
{
ushort a = 0b;
bool* b = cast(bool
question in the header, code in the body, execute on a X86 or
X86_64 CPU
```d
module test;
void setIt(ref bool b) @safe
{
b = false;
}
void main(string[] args)
{
ushort a = 0b;
bool* b = cast(bool*)
setIt(*b);
assert(a == 0b); // what
|--- |FIXED
--- Comment #5 from Dlang Bot ---
dlang/dmd pull request #16431 "Fix Bugzilla 24525 - ref lambda not parsed at
start of ExpressionStat…" was merged into master:
- 3c3be0716da1b6d2cdbe2ca6517a8b1cec6d7ae2 by Nick Treleaven:
Fix Bugzilla 24525 - ref lambda not parse
created dlang/dmd pull request #16431 "Fix Bugzilla 24525 - ref lambda
not parsed at start of ExpressionStat…" fixing this issue:
- Fix Bugzilla 24525 - ref lambda not parsed at start of ExpressionStatement
https://github.com/dlang/dmd/pull/16431
--
https://issues.dlang.org/show_bug.cgi?id=24525
Nick Treleaven changed:
What|Removed |Added
Assignee|nob...@puremagic.com|n...@geany.org
--
https://issues.dlang.org/show_bug.cgi?id=24525
basile-z changed:
What|Removed |Added
Summary|auto ref lambda exp not |auto ref lambda exp
e
none.
The parser should lookup after `auto`. If next is `(` or if next two are `ref`
then `(`, then it should takes the path of expression.
> It is unfortunate that the function literal syntax starting `ref` or `auto
> ref` was added, when the function/delegate keyword starting forms can alrea
---
> A declaration `ref () {return a;}` gets parsed
Sorry, that may be what is happening, but there is no identifier for the
declaration, so it should try to parse an ExpressionStatement.
--
edence.
For:
> ref () {return a;}() = 0;
A declaration `ref () {return a;}` gets parsed, not an ExpressionStatement. So
I think this issue is invalid.
It is unfortunate that the function literal syntax starting `ref` or `auto ref`
was added, when the function/delegate keyword starting forms ca
https://issues.dlang.org/show_bug.cgi?id=24525
Issue ID: 24525
Summary: auto ref lambda exp not parsed if used as left-most
expression in a expression statement
Product: D
Version: D2
Hardware: All
OS: All
updated dlang/dmd pull request #16381 "[foreach] Deprecate `ref` for
array index or range parameter" fixing this issue:
- Fix Bugzilla 24232 - ref for index of foreach for arrays is not allowed by
spec but accepted by compiler
https://github.com/dlang/dmd/pull/16381
--
created dlang/dmd pull request #16381 "[foreach] Deprecate `ref` for
array index or range parameter" fixing this issue:
- Deprecate `ref` for array index or range foreach parameter
Fix Bugzilla 24499 - foreach over a ref parameter to an rvalue should be an
error
Fix Bugzilla 2
https://issues.dlang.org/show_bug.cgi?id=24499
elpenguin...@gmail.com changed:
What|Removed |Added
CC||elpenguin...@gmail.com
--- Comment
https://issues.dlang.org/show_bug.cgi?id=24499
Issue ID: 24499
Summary: foreach over a ref parameter to an rvalue should be an
error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
|--- |FIXED
--- Comment #2 from Dlang Bot ---
dlang/dmd pull request #16364 "Fix Bugzilla 24485 - Invalid implicit ref return
reinterpret cast for structs with copy constructor" was merged into master:
- a93a57e74b0ce82e6c01b8ca64bfed2ddbeabc0b by RazvanN7:
Fix Bugzilla 24485
---
@RazvanN7 created dlang/dmd pull request #16364 "Fix Bugzilla 24485 - Invalid
implicit ref return reinterpret cast for structs with copy constructor" fixing
this issue:
- Fix Bugzilla 24485 - Invalid implicit ref return reinterpret cast for structs
with copy constructor
https://github.com/dlan
https://issues.dlang.org/show_bug.cgi?id=24485
Issue ID: 24485
Summary: Invalid implicit ref return reinterpret cast for
structs with copy constructor
Product: D
Version: D2
Hardware: All
OS: All
https://issues.dlang.org/show_bug.cgi?id=20075
Nick Treleaven changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=13168
Nick Treleaven changed:
What|Removed |Added
CC||turkey...@gmail.com
--- Comment #1 from
||n...@geany.org
--- Comment #1 from Nick Treleaven ---
Same when passing a bitfield as a ref argument:
struct S
{
uint a:1,
b:1,
c:1;
}
void f(ref uint b) { b++; }
void main()
{
S s;
s.a.f; // allowed! Silently does nothing
assert(s.a == 0
https://issues.dlang.org/show_bug.cgi?id=24385
Issue ID: 24385
Summary: Slicing a static array binds as non-ref when using
auto ref
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
for reference, C# (I tested .NET 8) also rejects treating `this` as an
lvalue:
```csharp
C c = new C();
c.mem();
class C
{
public void mem()
{
foo(ref this);
this = new C();
}
static void foo(ref C c)
{
c = null
||n...@geany.org
Resolution|--- |FIXED
--- Comment #2 from Nick Treleaven ---
Fixed by https://github.com/dlang/dmd/pull/15793:
/home/nick/os/rval.d(1): Error: cannot create default argument for `ref` /
`out` parameter from constant `123`
/home/nick
After switching to dmd v2.105.3 I get this warnings almost
everywhere. Do I really have to fork msgpack-d in order to get
rid of these warnings?
Now I replaced every "in ref" with "in" in my own code but I do
not add that preview flag to the compiler invocation. Is that
safe?
https://issues.dlang.org/show_bug.cgi?id=24265
Paul Backus changed:
What|Removed |Added
Summary|ref delegate no longer |ref delegate literal
---
Correction, it's not a diagnostic problem--the types are printed differently
because they are actually considered different by the compiler. For example,
this:
---
void test()
{
int local;
ref int explicit() pure nothrow @nogc @safe return;
ref int inferred() pure nothrow @nogc @safe => lo
https://issues.dlang.org/show_bug.cgi?id=24265
--- Comment #4 from Paul Backus ---
Looks like this only happens when the return attribute is inferred.
---
void test()
{
int a;
ref int f();
ref int g() return;
ref int h() => a; // return inferred
typeof() dg;
https://issues.dlang.org/show_bug.cgi?id=24265
Adam D. Ruppe changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Adam D.
from Paul Backus ---
Introduced by DMD PR 14142:
https://issues.dlang.org/show_bug.cgi?id=24265
Looks like maybe this isn't a behavioral bug, but a bad error message: the
actual problem is that `ref int delegate() return` does not convert to `ref int
delegate()`, but the compiler does not print
https://issues.dlang.org/show_bug.cgi?id=24265
--- Comment #2 from Paul Backus ---
Oops, pasted the wrong link; the introducing PR is here:
https://github.com/dlang/dmd/pull/14142
--
https://issues.dlang.org/show_bug.cgi?id=24265
Issue ID: 24265
Summary: ref delegate no longer implicitly converts to
unannotated type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=24263
Issue ID: 24263
Summary: -preview=bitfields: Bit field address escapes through
`ref`
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=24024
anonymous4 changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=21521
Nick Treleaven changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=2753
--- Comment #16 from Nick Treleaven ---
*** Issue 21521 has been marked as a duplicate of this issue. ***
--
|--- |FIXED
--- Comment #2 from Dlang Bot ---
dlang/dlang.org pull request #3699 "[spec] Improve `opApply` docs" was merged
into master:
- ec20daf236f6b685c51b629430f554abf4c2fceb by Nick Treleaven:
[spec] Improve `opApply` docs
Show grammar for signature.
Don't require `ref
https://issues.dlang.org/show_bug.cgi?id=24024
Iain Buclaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://issues.dlang.org/show_bug.cgi?id=24232
Issue ID: 24232
Summary: ref for index of foreach for arrays is not allowed by
spec but accepted by compiler.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
https://issues.dlang.org/show_bug.cgi?id=24024
--- Comment #12 from Dlang Bot ---
dlang/dmd pull request #15771 "merge stable" was merged into master:
- 8a8d03d88a7a17082aca132f1be776f945cdda85 by Martin Kinkelin:
[stable] Revert "fix Issue 24024 - cannot pass class this to ref
https://issues.dlang.org/show_bug.cgi?id=24024
--- Comment #11 from Dlang Bot ---
dlang/dmd pull request #15637 "[stable] Revert "fix Issue 24024 - cannot pass
class this to ref class"" was merged into stable:
- 1fed77b1e597280e91823a47310867e8df91f748 by Martin Kinkelin:
|--- |FIXED
--- Comment #3 from Dlang Bot ---
dlang/dmd pull request #15705 "Fix Issue 24168 - Corrupted if TLS values are
passed in ref parameters" was merged into master:
- fe858d91b7df8a770765f78286395259cca0f697 by Hiroki Noda:
Fix Issue 24168 - Corrupted if TLS values are pas
created dlang/dmd pull request #15705 "Fix Issue 24168 - Corrupted if
TLS values are passed in ref parameters" fixing this issue:
- Fix Issue 24168 - Corrupted if TLS values are passed in ref parameters
when compiling with -fPIE
https://github.com/dlang/dmd/pull/15705
--
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
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 -
https://issues.dlang.org/show_bug.cgi?id=24176
Nick Treleaven changed:
What|Removed |Added
Keywords||spec
--
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
https://issues.dlang.org/show_bug.cgi?id=24168
--- Comment #1 from kub...@gmail.com ---
I've tried with DMD2.088 (which -fPIE was introduced) and got the same result.
Perhaps it has been this way all along.
--
https://issues.dlang.org/show_bug.cgi?id=24168
Issue ID: 24168
Summary: Corrupted if TLS values are passed in ref parameters
when compiling with -fPIE
Product: D
Version: D2
Hardware: x86_64
OS: Linux
created dlang/dmd pull request #15596 "Fix isLvalue error message"
fixing this issue:
- Fix isLvalue error message
Requiring an lvalue is not the same as requiring modification.
Fix Issue 23791 - Rvalue default argument for ref parameter gives misleading
error.
https://github.com
On Wednesday, 6 September 2023 at 12:15:02 UTC, Adam D Ruppe
wrote:
On Wednesday, 6 September 2023 at 12:04:40 UTC, d007 wrote:
extern(C) int test(ref scope const(ubyte)[32] b);
extern(C) int test(ref scope const(ubyte[32]) b);
These are the same thing since the ref cannot be rebound
anyway
On Wednesday, 6 September 2023 at 12:04:40 UTC, d007 wrote:
extern(C) int test(ref scope const(ubyte)[32] b);
extern(C) int test(ref scope const(ubyte[32]) b);
These are the same thing since the ref cannot be rebound anyway;
a static array just is its contents.
```d
extern(C) int test(ref scope const(ubyte)[32] b);
```
This will automatic become this in ctfe relection
```d
extern(C) int test(ref scope const(ubyte[32]) b);
```
LDC2 1.34.0 DMD v2.104.2
https://issues.dlang.org/show_bug.cgi?id=24024
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #10 from Nick
] Document `return` parameters without `scope`
Part of Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted
missing.
Add 'Struct Return Methods' subheading.
https://github.com/dlang/dlang.org/pull/3619
--
https://issues.dlang.org/show_bug.cgi?id=24024
Tim changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
|
https://issues.dlang.org/show_bug.cgi?id=24024
Tim changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
|
|--- |FIXED
--- Comment #9 from Dlang Bot ---
dlang/dmd pull request #15389 "fix Issue 24024 - cannot pass class this to ref
class" was merged into master:
- 7d9679081f79e94793a13829e3adb54809e2da4e by Walter Bright:
fix Issue 24024 - cannot pass class this to ref class
https://
---
@WalterBright created dlang/dmd pull request #15389 "fix Issue 24024 - cannot
pass class this to ref class" fixing this issue:
- fix Issue 24024 - cannot pass class this to ref class
https://github.com/dlang/dmd/pull/15389
--
https://issues.dlang.org/show_bug.cgi?id=24024
Adam D. Ruppe changed:
What|Removed |Added
CC||destructiona...@gmail.com
--
https://issues.dlang.org/show_bug.cgi?id=24024
--- Comment #7 from Walter Bright ---
Consider UFCS and the ability to do a.foo() and foo(a). When `this` behaves
differently than a parameter, it generates a corner case with surprise
behavior.
Early on I spent much care to make the address of a
https://issues.dlang.org/show_bug.cgi?id=24024
--- Comment #6 from FeepingCreature ---
I guess I'm just allergic to ref-passing variables that you cannot see declared
anywhere. In your example, C c1 is explicitly declared; in the original
example, it's implicitly declared by the method call. IMO
(c1);
}
}
void foo(ref C c2) { c2 = null; }
C c3 = new C;
C.mem(c3); // c1 is a copy of c3
assert(c3 is null); // c1 is set to null, not c3
> And what about if `c` is genuinely an rvalue, such as `C createC();
> createC.mem;`?
Rvalues cannot be passed by ref.
13116 created a spe
from FeepingCreature ---
I mean, in the extreme, if this was allowed, shouldn't this happen?
class C
{
void mem()
{
foo(this);
}
}
void foo(ref C c) { c = null; }
C c = new C;
c.mem;
assert(c is null);
And what about if `c` is genuinely an rvalue, such as `C createC
https://issues.dlang.org/show_bug.cgi?id=13116
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=24024
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=24024
--- Comment #2 from Walter Bright ---
Looking into the code, the reason the match fails is because `this` for a class
is considered only an rvalue, not an lvalue.
--
---
This is the behavior I would expect - a class-ref `this` is special and not to
be mutated. What if `foo()` sets it to null?
--
https://issues.dlang.org/show_bug.cgi?id=24024
Issue ID: 24024
Summary: cannot pass class this to ref class
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
On Monday, 19 June 2023 at 18:19:18 UTC, mw wrote:
2) `inout T` alone
Steve covered everything, though you might also like to read the
inout spec:
https://dlang.org/spec/const3.html#inout
On 6/19/23 2:19 PM, mw wrote:
Hi, I just saw this line:
https://github.com/dlang/dmd/blob/master/druntime/src/core/stdcpp/vector.d#LL66C5-L66C39
```
66: ref inout(T) opIndex(size_t index) inout pure nothrow @safe
@nogc { return as_array[index]; }
```
I'm wondering if the `ref
Hi, I just saw this line:
https://github.com/dlang/dmd/blob/master/druntime/src/core/stdcpp/vector.d#LL66C5-L66C39
```
66:ref inout(T) opIndex(size_t index) inout pure nothrow
@safe @nogc { return as_array[index]; }
```
I'm wondering if the `ref` and `inout` redundant here
On Sunday, 18 June 2023 at 19:22:45 UTC, Paul Backus wrote:
No, there is no way to pass template arguments to a constructor
without using `__ctor`.
My recommendation is to use a free function or a `static`
method instead. For example:
```d
import std.stdio;
struct Test {}
Test
On Sunday, 18 June 2023 at 19:05:19 UTC, rempas wrote:
On Sunday, 18 June 2023 at 18:17:16 UTC, Paul Backus wrote:
`__ctor` doesn't create a new object, it initializes an
existing object. You need to create the object first, then
call `__ctor` on it:
```d
void main() {
Test test;
On Sunday, 18 June 2023 at 18:17:16 UTC, Paul Backus wrote:
`__ctor` doesn't create a new object, it initializes an
existing object. You need to create the object first, then call
`__ctor` on it:
```d
void main() {
Test test;
test.__ctor!("non_def")("Hello");
}
```
Thank you! Do you
t;)(string reg_arg) {
writeln("reg_arg: ", reg_arg);
}
}
void main() {
auto test = Test.__ctor!("non_def")("Hello");
}
```
And the error I get: `test.d(10): Error: need `this` for `this`
of type `ref @safe Test(string reg_arg)`
`__ctor` doesn't create
arg: ", reg_arg);
}
}
void main() {
auto test = Test.__ctor!("non_def")("Hello");
}
```
And the error I get: `test.d(10): Error: need `this` for `this`
of type `ref @safe Test(string reg_arg)`
created dlang/dlang.org pull request #3619 "[spec/function] Document
`return` parameters without `scope`" fixing this issue:
- [spec/function] Document `return` parameters without `scope`
Fixes Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted
missing.
https://
https://issues.dlang.org/show_bug.cgi?id=17934
--- Comment #12 from Nick Treleaven ---
If you define `front` as `return`, *not* `return scope`:
Elem front() @safe return
You get an error for:
elem = l.front;
I think that fixes this issue, though that feature may need documenting.
--
https://issues.dlang.org/show_bug.cgi?id=16362
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
from Paul Backus ---
One workaround for this is to pass the value to a callback as a scope
parameter, rather than returning it:
---
void withList(alias callback)()
{
scope l = (() @trusted => List(malloc(1)))();
callback(l);
}
void test() @safe
{
Elem elem;
withList!((scope re
https://issues.dlang.org/show_bug.cgi?id=2753
--- Comment #15 from Dlang Bot ---
@Bolpat created dlang/dmd pull request #15269 "Primary Type Syntax" fixing this
issue:
- Fix issue 2753 - add good case tests
https://github.com/dlang/dmd/pull/15269
--
https://issues.dlang.org/show_bug.cgi?id=2753
--- Comment #14 from Dlang Bot ---
@Bolpat created dlang/dlang.org pull request #3616 "Primary Type Syntax" fixing
this issue:
- Fix Issue 2753
https://github.com/dlang/dlang.org/pull/3616
--
|--- |FIXED
--- Comment #4 from Dlang Bot ---
dlang/dmd pull request #15240 "Fix Issue 23914 - auto ref resolution on return
value prevented by noreturn" was merged into master:
- 883de397fb3a1405bdfaaa985abc905049c41fb0 by RazvanN7:
Fix Issue 23914 - auto ref resolution on re
https://issues.dlang.org/show_bug.cgi?id=2753
--- Comment #13 from Dlang Bot ---
@Bolpat updated dlang/dmd pull request #15245 "Fix Issue 2753" fixing this
issue:
- Fix issue 2753 - add good case tests
https://github.com/dlang/dmd/pull/15245
--
https://issues.dlang.org/show_bug.cgi?id=2753
--- Comment #12 from Dlang Bot ---
@ntrel updated dlang/dmd pull request #15243 "[new syntax] Support `function`
`ref` Type Parameters for function pointer types" fixing this issue:
- Fix Issue 2753 - Cannot declare pointer to function ret
---
@RazvanN7 created dlang/dmd pull request #15240 "Fix Issue 23914 - auto ref
resolution on return value prevented by noreturn" fixing this issue:
- Fix Issue 23914 - auto ref resolution on return value prevented by noreturn
https://github.com/dlang/dmd/pull/15240
--
https://issues.dlang.org/show_bug.cgi?id=23917
--- Comment #2 from Vladimir Panteleev ---
(Oops, ignore above comment, got my return types mixed up.)
--
https://issues.dlang.org/show_bug.cgi?id=23917
--- Comment #1 from Vladimir Panteleev ---
Something weird also happens when you try to pass it as a parameter to a ref
function. A non-templated function works, but a function templated on the
argument/return type fails
https://issues.dlang.org/show_bug.cgi?id=23917
Issue ID: 23917
Summary: "ref" in alias this call not detected in "auto ref"
return resolution
Product: D
Version: D2
Hardware: All
OS: Al
of noreturn in object -
we "undo" the null pointer dereference by using "ref". With an alternative
definition of noreturn, e.g. `typeof(assert(false))`, I'm not sure that this
makes sense any more.
--
1 - 100 of 5022 matches
Mail list logo
