On 6/9/23 06:05, An Pham wrote:
Getting with below error for following codes. Look like bug?
onlineapp.d(61): Error: scope variable `a` assigned to non-scope
parameter `a` calling `foo`
@safe:
struct A(S = string)
{
@safe:
S s;
void delegate() c;
}
On Friday, 9 June 2023 at 04:05:27 UTC, An Pham wrote:
Getting with below error for following codes. Look like bug?
Filed as https://issues.dlang.org/show_bug.cgi?id=23985
You can work around it by marking parameter `a` as `return scope`
Getting with below error for following codes. Look like bug?
onlineapp.d(61): Error: scope variable `a` assigned to non-scope
parameter `a` calling `foo`
@safe:
struct A(S = string)
{
@safe:
S s;
void delegate() c;
}
struct B(S = string)
{
@safe
why foo2 is not inferred as scope which is shorter scope then
foo1?
import std.stdio;
@safe:
class Obj {@safe: override string toString() { return "obj";
} }
struct Foo1
{@safe:
this(Obj obj) { this._obj = obj; }
~this() { _obj = null; } // do something with
On Monday, 1 August 2022 at 17:07:43 UTC, wjoe wrote:
On Monday, 1 August 2022 at 13:09:01 UTC, Kagamin wrote:
Bar.toString is typed `@system`.
Even if I'd declare everything @safe: at module scope?
I wrote that on my phone and it got a bit messy...
``` D
module x;
@safe:
struct Foo()
{
On Monday, 1 August 2022 at 13:09:01 UTC, Kagamin wrote:
Bar.toString is typed `@system`.
Even if I'd declare everything @safe: at module scope?
Bar.toString is typed `@system`.
fmt)
{}
}
@safe unittest {
import std.conv:to;
Foo!() foo; foo.to!string;
Bar bar; bar.to!string; // 25
}
# dmd d.d -dip1000 -unittest -main
d.d(25) Error: @safe function d.__unittest_121_C7 cannot call
@system function std.conv.to!string.to!(Bar).to
/usr/lib/dmd/2.099/import/std/conv.d
On Saturday, 2 July 2022 at 09:42:17 UTC, Loara wrote:
But you first said "The compiler should deduce if a `scope`
pointer points to heap allocated data or not" and when someone
tells you this should happen only for not `scope` pointers you
say "But the compiler doesn't do that".
This discuss
On Thursday, 30 June 2022 at 21:30:39 UTC, Ola Fosheim Grøstad
wrote:
I don't understand what you mean, it could, but it doesn't. And
if it did then you would not need `scope`…
If the compiler doesn't optimize your code is a compiler issue.
When you use the `scope` attribute you're [forcing th
On Thursday, 30 June 2022 at 19:56:38 UTC, Loara wrote:
The deduction can happen even if you don't use `scope`
attribute.
I don't understand what you mean, it could, but it doesn't. And
if it did then you would not need `scope`…
When you use `scope` attribute you're saying to compiler "You
On Tuesday, 28 June 2022 at 21:58:48 UTC, Ola Fosheim Grøstad
wrote:
Not when connect returns, but the scope that connect was called
from. Still, this can be deduced, you just have to give the
scopes an ordering.
The deduction can happen even if you don't use `scope` attribute.
When you use `
life times.
Ex. from your example then even if the "node struct" you pass
was allocated on the stack, then the memory the "next" pointer
points to might not be allocated same place.
Unless I'm misunderstanding what you're trying to say.
You did :). If you look
On Tuesday, 28 June 2022 at 21:58:48 UTC, Ola Fosheim Grøstad
wrote:
not-scoped variable (`a.next` is not `scope` since this
attribute is not transitive)
Well, that is a flaw, if the object is stack allocated then the
fields are too.
Not necessarily, especially if the fields aren't value
On Tuesday, 28 June 2022 at 21:40:44 UTC, Loara wrote:
When `connect()` returns may happen that `b` is destroyed but
`a` not, so `a.next` contains a dangling pointer that
Not when connect returns, but the scope that connect was called
from. Still, this can be deduced, you just have to give the
On Friday, 24 June 2022 at 18:31:14 UTC, Ola Fosheim Grøstad
wrote:
The objects are in the calling function, not in the connect()
function. So they are not destroyed when the connect() function
returns.
When `connect()` returns may happen that `b` is destroyed but `a`
not, so `a.next` contain
On Friday, 24 June 2022 at 17:53:07 UTC, Loara wrote:
Why you should use `scope` here?
I probably shouldn't. That is why I asked in the «learn» forum…
A `scope` pointer variable may refer to a stack allocated
object that may be destroyed once the function returns.
The objects are in the cal
On Thursday, 23 June 2022 at 16:08:01 UTC, Ola Fosheim Grøstad
wrote:
How am I supposed to write this:
```d
import std;
@safe:
struct node {
node* next;
}
auto connect(scope node* a, scope node* b)
{
a.next = b;
}
void main()
{
node x;
node y;
connect(&x,&y);
}
```
Erro
On Friday, 24 June 2022 at 09:08:25 UTC, Dukc wrote:
On Friday, 24 June 2022 at 05:11:13 UTC, Ola Fosheim Grøstad
wrote:
No, the lifetime is the same if there is no destructor. Being
counter intuitive is poor usability.
It depends on whether you expect the rules to be smart or
simple. Smart
On Friday, 24 June 2022 at 05:11:13 UTC, Ola Fosheim Grøstad
wrote:
No, the lifetime is the same if there is no destructor. Being
counter intuitive is poor usability.
It depends on whether you expect the rules to be smart or simple.
Smart is not necessarily better, as the Unix philosophy tel
On Friday, 24 June 2022 at 03:03:52 UTC, Paul Backus wrote:
On Thursday, 23 June 2022 at 21:34:27 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It's a weird rule for sure.
Another slightly annoying thing is that it cares about
destruction order wh
On Thursday, 23 June 2022 at 21:34:27 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It's a weird rule for sure.
Another slightly annoying thing is that it cares about
destruction order when there are no destructors.
If there are no destructors th
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It's a weird rule for sure.
Another slightly annoying thing is that it cares about
destruction order when there are no destructors.
If there are no destructors the lifetime ought to be considered
the same for variables in the same s
On Thursday, 23 June 2022 at 21:05:57 UTC, ag0aep6g wrote:
It means "may be returned or copied to the first parameter"
(https://dlang.org/spec/function.html#param-storage). You
cannot escape via other parameters. It's a weird rule for sure.
Too complicated for what it does… Maybe @trusted isn'
On Thursday, 23 June 2022 at 20:27:44 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 June 2022 at 19:38:12 UTC, ag0aep6g wrote:
```d
void connect(ref scope node a, return scope node* b)
```
Thanks, so the `return scope` means «allow escape», not
necessarily return?
It means "may be returne
On Thursday, 23 June 2022 at 19:38:12 UTC, ag0aep6g wrote:
```d
void connect(ref scope node a, return scope node* b)
```
Thanks, so the `return scope` means «allow escape», not
necessarily return?
But that only works for this very special case. It falls apart
when you try to add a third nod
On Thursday, 23 June 2022 at 16:08:01 UTC, Ola Fosheim Grøstad
wrote:
How am I supposed to write this:
```d
import std;
@safe:
struct node {
node* next;
}
auto connect(scope node* a, scope node* b)
{
a.next = b;
}
void main()
{
node x;
node y;
connect(&x,&y);
}
```
Erro
How am I supposed to write this:
```d
import std;
@safe:
struct node {
node* next;
}
auto connect(scope node* a, scope node* b)
{
a.next = b;
}
void main()
{
node x;
node y;
connect(&x,&y);
}
```
Error: scope variable `b` assigned to non-scope `(*a).next`
On Friday, 6 May 2022 at 17:17:01 UTC, Dennis wrote:
On Friday, 6 May 2022 at 09:24:06 UTC, vit wrote:
[...]
They were recently updated to match the implementation in 2.100.
[...]
`return scope` means pointer members (such `this.ptr`, `C.ptr`)
may not escape the function, unless they are
On Friday, 6 May 2022 at 09:24:06 UTC, vit wrote:
It look like examples at page
https://dlang.org/spec/function.html#ref-return-scope-parameters are no longer relevant.
They were recently updated to match the implementation in 2.100.
What difference are between `return scope`, `scope return`
Hello, new dmd (2.100) has return/scope changes.
It look like examples at page
https://dlang.org/spec/function.html#ref-return-scope-parameters
are no longer relevant.
What difference are between `return scope`, `scope return` and
`return`?
Why `void* ptr` in struct change effect of `scope r
ou to
escape `scope` variables, the compiler will still try to infer
`scope`, `return scope` or `return ref` on its parameters as far
as it can, and that can spawn errors in its `@safe` callers.
Swapping `scope` variables is not something you can do in `@safe`
code with dip1000's curren
Hello,
Why doesn't this code compile?
```d
static struct Foo{
void *ptr;
void proxySwap1(scope ref typeof(this) rhs)scope pure nothrow
@trusted @nogc{
auto tmp = this.ptr;
this.ptr = rhs.ptr;
rhs.ptr = tmp;
}
void proxySwap2()(scope ref typeof(this) rh
On Tuesday, 27 April 2021 at 14:44:48 UTC, Adam D. Ruppe wrote:
On Tuesday, 27 April 2021 at 14:28:12 UTC, jmh530 wrote:
However, should it ever matter if you escape an immutable?
Your example is a pretty clear case of use-after-free if gloin
actually did escape the reference and kept it afte
On Tuesday, 27 April 2021 at 14:28:12 UTC, jmh530 wrote:
However, should it ever matter if you escape an immutable?
Your example is a pretty clear case of use-after-free if gloin
actually did escape the reference and kept it after main returned.
I tried basically the same thing in Rust and i
What is the motivation for DIP1000 also applying to immutable?
For instance, in the code (compiled with -dip1000), adapted from
the spec [1], you get the same errors with immutable function
parameters as you would with mutable ones. However, should it
ever matter if you escape an immutable
On Monday, 31 August 2020 at 05:46:45 UTC, ag0aep6g wrote:
`ref` kind of implies `scope` [1]. You don't need to type it
out. When you do type out `scope ref const(Price)`, the `scope`
actually doesn't apply to the `ref` but to the pointers in
`Price` (whereas the `scope` in `scope const(Price)[
--
class MinPointerRecorder
{
@nogc nothrow pure @safe:
void update(scope const(Price)[] prices) scope
{
foreach (price; prices)
{
update(price);
}
}
void update( /* scope */ ref const(Price) price) scope
{
if (!minPrice || pri
// NG
// return A(a);
// return A(a.tag);
}
[...]
I understand those errors are DIP1000 language design.
However I suppose that DIP1000 check can permit immutable
pointer in some cases.
If I understand correctly, your point is that an enum pointer
is guaranteed to refer to static d
[...]
I understand those errors are DIP1000 language design.
However I suppose that DIP1000 check can permit immutable pointer in
some cases.
If I understand correctly, your point is that an enum pointer is
guaranteed to refer to static data, so it could be exempt from `scope`
checks.
At a gl
mal copy constructor.
/+
this (ref return scope const A a) @nogc nothrow pure @safe
scope
{
this.tag = a.tag.unscope;
}
+/
}
A createA() @safe
{
scope a = A(Tag.tag);
// OK
return A(a);
}
I understand those errors are DIP1000 language design.
However I suppos
ope ref
T` behaves the same as `scope T*` ?
Regarding `scope` more generally, DIP1000 shows as "superseded"
-- **can I still rely on this document for guidance?** We have
a `-dip1000` flag but a superseded DIP. The discordance is
extremely confusing.
It is, for users and compilers
haves the same as
`scope T*` ?
I don't think there's documentation for `scope ref`. That may be because
`scope` doesn't affect `ref`. This is a corner of DIP 1000 that keeps
confusing me.
Consider this function:
int* fp(scope int** p) { return *p; }
This compiles wit
of `scope` with ref type parameters, but the
example given is pointer-based. Is it correct that `scope ref T`
behaves the same as `scope T*` ?
Regarding `scope` more generally, DIP1000 shows as "superseded"
-- **can I still rely on this document for guidance?** We have a
`-dip1000` f
On Monday, 29 June 2020 at 06:21:43 UTC, ag0aep6g wrote:
Since `local` and `writeln` are templates, the attributes for
their parameters are inferred from their bodies. `local!(int*)`
doesn't do anything with the parameter, so it's inferred as
`scope`. `writeln!(int*)` apparently does something
}
The signatures of `std.stdio.writeln` and `local` are the same (see
`writeln` [1]). Yet, with '$ dmd -preview=dip1000' the call to `local`
compiles, while the call to `writeln` doesn't.
Since `local` and `writeln` are templates, the attributes for their
parameters are inferred fr
` are the same
(see `writeln` [1]). Yet, with '$ dmd -preview=dip1000' the call
to `local` compiles, while the call to `writeln` doesn't.
Is that an instance of [2]?
[1]
https://github.com/dlang/phobos/blob/v2.092.1/std/stdio.d#L3865
[2] https://issues.dlang.org/show_bug.cgi?id=20023
On Friday, 12 June 2020 at 12:49:08 UTC, Steven Schveighoffer
wrote:
I was just looking through the DIPs in the system, and noticed
that DIP1000 is "superseded".
I thought that was odd, since it's in the compiler as a switch
and is a major driver of discussion and hope for memo
Logic is apparently still in flux, too early to document.
I was just looking through the DIPs in the system, and noticed that
DIP1000 is "superseded".
I thought that was odd, since it's in the compiler as a switch and is a
major driver of discussion and hope for memory safety.
In the DIP it says [1]:
"This DIP did not complet
On Wednesday, 24 July 2019 at 16:23:48 UTC, Paul Backus wrote:
On Wednesday, 24 July 2019 at 12:54:51 UTC, aliak wrote:
[...]
It should go on the constructor's parameter; i.e.,
this(auto return ref T value) { /* ... */ }
Under the hood, a constructor actually returns the constructed
value b
On Wednesday, 24 July 2019 at 12:54:51 UTC, aliak wrote:
Trying to get dip1000 flag in use. I have this error:
Error: returning Optional(null, false).this(value) escapes a
reference to parameter value, perhaps annotate with return
in this function:
public auto some(T)(auto ref T value
Trying to get dip1000 flag in use. I have this error:
Error: returning Optional(null, false).this(value) escapes a
reference to parameter value, perhaps annotate with return
in this function:
public auto some(T)(auto ref T value) {
return Optional!T(value); // <-- error on this l
On Tuesday, 18 June 2019 at 21:57:32 UTC, Jonathan M Davis wrote:
-snip-
Thank you, it's clear to me now :)
On Tuesday, June 18, 2019 8:53:31 AM MDT Emmanuelle via Digitalmars-d-learn
wrote:
> Hi, I've been reading about DIP25 and DIP1000 and I'm not quite
> sure if I understand the difference between the two—is DIP1000
> supposed to be a rework of DIP25? And what's the differen
Hi, I've been reading about DIP25 and DIP1000 and I'm not quite
sure if I understand the difference between the two—is DIP1000
supposed to be a rework of DIP25? And what's the difference
between `return ref` and `return scope`? Also, will there be any
compiler version where
This is a bug. Please file.
Not sure what the solution is, because dip1000 makes scope a
storage class. So there's no way to tag what the input
parameter points at.
-Steve
The parameter pointer outlives the the &local, i.e. cannot be
guaranteed that it doesn't escape, which is
On Thursday, 16 May 2019 at 21:21:51 UTC, Max Haughton wrote:
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to
not escape (Returning &local directly does not compile)
This is a bug, as can be showed by repeating the call to
(*boi).writeln - sudden
On 5/16/19 10:21 PM, Max Haughton wrote:
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to not
escape (Returning &local directly does not compile)
Answer to subject: no. This is a bug. Please file.
Not sure what the solution is, because dip
https://run.dlang.io/is/cKFsXh
Should this compile, or is return scope T* down to the user to
not escape (Returning &local directly does not compile)
On Sunday, 10 February 2019 at 20:04:29 UTC, Per Nordlöw wrote:
Is there a way to query if the -dip1000 flag has been passed to
the compiler? I need it for enabling certain DIP-1000 escape
analysis tests only when -dip1000 has been passed.
For instance
static assert(!__traits(compiles
[...]
> >
> > A quick grep of Phobos shows a version(DIP1000) block in
> > std/typecons.d, which appears to be used to make it so that a
> > particular unittest block is only compiled in when -dip1000 is
> > used, so it looks like there's a version identifier
On Monday, 11 February 2019 at 09:29:13 UTC, Jonathan M Davis
wrote:
On Sunday, February 10, 2019 1:04:29 PM MST Per Nordlöw via
Digitalmars-d- learn wrote:
[...]
A quick grep of Phobos shows a version(DIP1000) block in
std/typecons.d, which appears to be used to make it so that a
On Sunday, February 10, 2019 1:04:29 PM MST Per Nordlöw via Digitalmars-d-
learn wrote:
> Is there a way to query if the -dip1000 flag has been passed to
> the compiler? I need it for enabling certain DIP-1000 escape
> analysis tests only when -dip1000 has been passed.
>
&g
On Sunday, 10 February 2019 at 20:04:29 UTC, Per Nordlöw wrote:
Or do I have to write a trait myself?
Oops, I had already posted that and got an answer at
https://forum.dlang.org/post/qglynupcootocnnnp...@forum.dlang.org
Is there a way to query if the -dip1000 flag has been passed to
the compiler? I need it for enabling certain DIP-1000 escape
analysis tests only when -dip1000 has been passed.
For instance
static assert(!__traits(compiles, {
char[] f
On Tuesday, 27 November 2018 at 08:56:47 UTC, sclytrack wrote:
---
How is a person able to understand this DIP?
./dmd -betterC -dip1000 test.d
I'll repeat: the DIP does not currently match the implementation.
I was not involved in any of it and have no idea what the diff
actual
On Monday, 26 November 2018 at 09:10:23 UTC, sclytrack wrote:
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b
On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote:
Did DIP1000 go through any review process? I'm seeing it is a
draft.
The previous DIP manager marked DIPs as Draft while they were
under review. I don't use that anymore. I left DIP1000 untouched
after I took ove
On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote:
Did DIP1000 go through any review process? I'm seeing it is a
draft.
Review links are at the very end.
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md
Keeps talking about a Drafts subdirectory. I don't see any
On Sunday, 25 November 2018 at 19:49:03 UTC, Stanislav Blinov
wrote:
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
...
What is rule 5?
...
Wouldn't you call it D3 because of the name mangling of
DIP1000 once activated by default?
That "rul
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
...
What is rule 5?
...
Wouldn't you call it D3 because of the name mangling of DIP1000
once activated by default?
That "rule 5" looks like a straight up mistake. As for D3...
IMHO, no, not
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b; // Ok
int* i = a;// Ok, scope is inferred
On Sat, 10 Nov 2018 16:25:40 +, Stanislav Blinov wrote:
> Yep, you just over-simplified the first case.
It is too simple to clearly illustrate why the code is invalid, but not so
simple that the compiler accepts that code.
> Consider:
>
> int* p;
> {
> int i;
> p = &i;
> }
> *p =
On Saturday, 10 November 2018 at 06:56:29 UTC, Neia Neutuladh
wrote:
The following code doesn't work with @safe -dip1000:
int* p;
int i;
p = &i;
i has a shorter lifetime than p, the compiler complains.
But this code does:
int i;
int* p;
p = &i;
The compi
On Sat, 10 Nov 2018 11:47:24 +, Nicholas Wilson wrote:
> On Saturday, 10 November 2018 at 06:56:29 UTC, Neia Neutuladh wrote:
>> Is this right?
>
> Are you sure you added @safe to the second example?
> https://run.dlang.io/is/2RbOwK fails to compile.
Maybe take another look at the post you're
On Saturday, 10 November 2018 at 06:56:29 UTC, Neia Neutuladh
wrote:
Is this right?
Are you sure you added @safe to the second example?
https://run.dlang.io/is/2RbOwK fails to compile.
The following code doesn't work with @safe -dip1000:
int* p;
int i;
p = &i;
i has a shorter lifetime than p, the compiler complains.
But this code does:
int i;
int* p;
p = &i;
In both cases, p can't point to i before i exists, and p ceases to exist
On 9/7/18 7:59 AM, Orfeo wrote:
On Friday, 7 September 2018 at 14:36:18 UTC, rikki cattermole wrote:
On 08/09/2018 2:29 AM, Orfeo wrote:
==> And why (maybe a silly question) `-dip1000` breaks my project so
badly without warning..
DIP 1000 is an experimental addition to D, that is yet to
On Friday, 7 September 2018 at 14:36:18 UTC, rikki cattermole
wrote:
On 08/09/2018 2:29 AM, Orfeo wrote:
==> And why (maybe a silly question) `-dip1000` breaks my
project so badly without warning..
DIP 1000 is an experimental addition to D, that is yet to be
complete.
It is a compi
On 08/09/2018 2:29 AM, Orfeo wrote:
==> And why (maybe a silly question) `-dip1000` breaks my project so
badly without warning..
DIP 1000 is an experimental addition to D, that is yet to be complete.
It is a compiler switch for a reason, it isn't ready for usage, only
some experimentation.
ems.
So I add FuzzyCopy library [1], I update dmd, then:
And why (maybe a silly question) `-dip1000`dip1000 my project
so badly without warning..
==> And why (maybe a silly question) `-dip1000` breaks my
project so badly without warning..
ights
Reserved written by Walter Bright
$ dub build --verbose
/usr/bin/dmd -dip1000 -dip25 -c
-of.dub/build/application-debug-linux.posix-x86_64-dmd_2082-C9F52D2A0CA0970ECB75169BD9B6C34D/jan.o -debug -g -w -version=VibeDefaultMain -version=VibeUseOpenSSL11 . -vcolumns
FAIL
.dub/
On Thursday, 28 June 2018 at 13:29:58 UTC, vit wrote:
Hello,
Is it possible to create scope wrapper initialized by non
default constructor with scope parameter?
something like this:
struct Wrapper{
int* p;
static Wrapper create(scope return int* p)@safe{
Wrapper w;
w.p
Hello,
Is it possible to create scope wrapper initialized by non default
constructor with scope parameter?
something like this:
struct Wrapper{
int* p;
static Wrapper create(scope return int* p)@safe{
Wrapper w;
w.p = p;
return w;
}
/++ This doesn't wor
My understanding is, currently read DIP1000 as:
"NB: this DIP is out of sync with -dip1000 compiler switch
implementation ...".
My own current problem fits well in this thread:
I want to push forward support of -dip1000 in phobos, testing
each module's compatibilit
isted.
My understanding is, currently read DIP1000 as:
"NB: this DIP is out of sync with -dip1000 compiler switch
implementation ...".
Yes, the representation of DIP1000.md deserves improvement: It
takes (too) much time to get a grip on it, maybe discouraging,
though the idea itself is not
On Sunday, 21 January 2018 at 10:04:36 UTC, Mike Franklin wrote:
What is/was `transition=safe`? I can't find any documentation
on it.
Well, I found
http://forum.dlang.org/post/gquxgusfhyigirfpe...@forum.dlang.org
But, didn't really clear much up for me.
Mike Franklin wrote:
And what does "NB" mean?
"nota bene". used as "pay attention to the following".
I found the following statement in the DIP1000 document
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
NB: this DIP is out of sync with -transition=safe
implementation available in dmd and pending a rewrite. Most key
points still apply though.
What is/was `transition=safe`? I
DIP1000 has a section on owning containers where it shows that
you can have a reference to a member of a struct that will not
outlive the struct itself. This seems to work through the
function opAssign being scope ref.
Why wouldn't you normally be allowed to make a scoped pointer to
a m
= ptr;
}
+/
}
void main()@safe{
int i;
auto x = Ptr(&i);
auto y = Ptr.create(&i);
}
I think this is a limitation of dip1000 that was not foreseen. I think
when you mark the parameter `return`, `this` isn't actually considered a
return value, is it? So it doesn't link the
How to manualy declare constructor for struct Ptr which work like
Ptr.create?
struct Ptr{
int* ptr;
static Ptr create(scope return int* ptr)@safe{
Ptr x;
x.ptr = ptr;
return x;
}
/++ This doesn't work:
this(scope return int* ptr)scope @safe{
On Monday, 11 December 2017 at 20:44:06 UTC, Eugene Wissner wrote:
On Monday, 11 December 2017 at 20:40:09 UTC, vit wrote:
This code doesn't compile with -dip1000:
struct Foo{
int foo;
ref int bar(){
return foo;
}
}
Error: returning `this.foo` escapes a referen
On Monday, 11 December 2017 at 20:40:09 UTC, vit wrote:
This code doesn't compile with -dip1000:
struct Foo{
int foo;
ref int bar(){
return foo;
}
}
Error: returning `this.foo` escapes a reference to parameter
`this`, perhaps annotate with `return`
How c
This code doesn't compile with -dip1000:
struct Foo{
int foo;
ref int bar(){
return foo;
}
}
Error: returning `this.foo` escapes a reference to parameter
`this`, perhaps annotate with `return`
How can be annotated this parameter with 'return ref' ?
ss of the result outlives the rvalue. The compiler should be able
> to tell that if I call id with an rvalue, the resulting reference can't
> escape the expression.
>
> So it's somewhat of a cross between dip1000 and dip25, but obviously
> neither flags it.
I would think that
ss, it's the fact that the
address of the result outlives the rvalue. The compiler should be able
to tell that if I call id with an rvalue, the resulting reference can't
escape the expression.
So it's somewhat of a cross between dip1000 and dip25, but obviously
neither flags it.
-Steve
mber 02, 2017 19:53:36 Q. Schroll via
> >> Digitalmars-d-learn>>
> >> wrote:
> >>> struct S { ref S id() return { return this; } }
> >>> void main() { S* p = &S().id(); }
> >>
> >> Well, if you make them @safe, it won'
1 - 100 of 107 matches
Mail list logo