https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #52 from Steven Schveighoffer ---
(In reply to Steven Schveighoffer from comment #51)
> then it works as expected. In this case, the compiler is copying the S(x)
> instance to the return value, and then destroying the original, though I'
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #51 from Steven Schveighoffer ---
(In reply to Tomer Filiba (weka) from comment #48)
> Steven, can we agree that the following snippet is NOT okay?
> Regardless of @safe, let's leave it out of question.
You are still not hooking copies
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #50 from Tomer Filiba (weka) ---
Btw, I tried adding to S
```
@disable void opPostMove(const ref S oldLocation) nothrow {}
```
But it doesn't have any effect (problem compiles and produces the same issue).
In C++, you can make types un
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #49 from Steven Schveighoffer ---
On discord, we worked out a case where the compiler is moving a struct and not
calling any opPostMove or other features (copy constructor, postblit, etc):
```d
import std.stdio;
struct S{
S* ptr;
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #48 from Tomer Filiba (weka) ---
Steven, can we agree that the following snippet is NOT okay?
Regardless of @safe, let's leave it out of question.
As a bonus, it this does not involve any library code/special moves/self
references. And
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #47 from Steven Schveighoffer ---
I should rephrase my query.
currently, if you create an appropriately written `opPostMove`, then the D
library calls that when it's doing a semantic move of your type (e.g. if you
use `std.algorithm.move
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #46 from Steven Schveighoffer ---
e.g.:
```d
struct S {
S* addr;
this(int dummy) { this.addr = &this; }
this(ref const S other) { this.addr = &this; }
static S create() { return S(1); }
}
```
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #45 from Steven Schveighoffer ---
I'm assuming you are missing some extra machinery here. You aren't expecting D
to automatically update your references for you, right? You at least need a
postblit/copy ctor.
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #44 from Eyal ---
Hi Steven, thanks for reaching out.
This example still fails on newest dmd:
struct S {
S* addr;
this(int dummy) { this.addr = &this; }
static S create() { return S(1); }
}
unittest
https://issues.dlang.org/show_bug.cgi?id=17448
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@gmail.com
--- Comment #43 f
https://issues.dlang.org/show_bug.cgi?id=17448
RazvanN changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=17448
Richard Cattermole changed:
What|Removed |Added
CC||alphaglosi...@gmail.com
--- Comment #41
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #40 from thomas.bock...@gmail.com ---
(In reply to thomas.bockman from comment #39)
> Are postblits even still broken?
Also, I tested all of the examples posted to this issue. On recent compilers
they all seem to either work correctly, or
https://issues.dlang.org/show_bug.cgi?id=17448
thomas.bock...@gmail.com changed:
What|Removed |Added
CC||thomas.bock...@gmail.com
--- Comme
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #38 from Walter Bright ---
DIP 1014:
https://github.com/dlang/DIPs/blob/38cec74a7471735559e3b8a7553f55102d289d28/DIPs/DIP1014.md
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #37 from Walter Bright ---
Looking at your example, I rewrote it into a nunnable form:
import core.stdc.stdio;
struct S {
int i;
this(int i) {
printf("this() %d\n", i);
this.i = i;
}
this(this) {
https://issues.dlang.org/show_bug.cgi?id=17448
Carsten Blüggel changed:
What|Removed |Added
CC||chi...@posteo.net
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #36 from Shachar Shemesh ---
Hello Walter,
I see two problems with your comment. The first is that I think you are missing
the real point of this bug report. It is not about controlling movability. It
is about being able to hook the obje
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #35 from Walter Bright ---
(In reply to Shachar Shemesh from comment #33)
> You cannot be notified when the object
> moves, and once it does, the global linked list will get completely
> corrupted.
That is correct, and you are right to b
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #34 from Eyal ---
Walter: Thanks, the RVO fixes are very useful and important - and will be part
of any future solution we have!
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #33 from Shachar Shemesh ---
Like we said earlier, the safe implications are important, but are not the core
of this bug report.
The problem is that, as things stand with D, certain types of programming
become impossible.
For example, c
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #32 from Walter Bright ---
I filed two bug reports based on Tomer's work:
https://issues.dlang.org/show_bug.cgi?id=18575
https://issues.dlang.org/show_bug.cgi?id=18576
which have PRs:
https://github.com/dlang/dmd/pull/7989
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #31 from Shachar Shemesh ---
Here goes:
(In reply to Andrei Alexandrescu from comment #30)
> Indeed it seems we are not supporting registration by address with ease for
> D value types.
Make that: at all. I understand that there are cas
https://issues.dlang.org/show_bug.cgi?id=17448
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=17448
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #30 from Andrei Alexandrescu ---
Indeed it seems we are not supporting registration by address with ease for D
value types.
There are good reasons for that; by allowing value types to be moved around we
avoid a swath of complications and
https://issues.dlang.org/show_bug.cgi?id=17448
Jonathan M Davis changed:
What|Removed |Added
CC||issues.dl...@jmdavisprog.co
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #28 from Tomer Filiba (weka) ---
My point is, @safe is so constrained that it's practically unusable, so I don't
consider it a viable solution for this problem.
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #27 from Tomer Filiba (weka) ---
(In reply to Andrei Alexandrescu from comment #25)
> > So... more special cases?
>
> That's a straight use of scope per DIP 1000, in fact the very design intent:
> scope in a function signature specifies
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #26 from Eyal ---
What solution is there for this use-case then?
We need objects to register themselves (i.e: set out-of-scope pointers to point
at them) and RAII-wise have them de-register themselves. While they are
registered, we need
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #25 from Andrei Alexandrescu ---
(In reply to Tomer Filiba (weka) from comment #24)
> > We should address this situation by having writeln take scope inputs. It
> > does
> > not escape any pointers.
>
> So... more special cases?
That's
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #24 from Tomer Filiba (weka) ---
> We should address this situation by having writeln take scope inputs. It does
> not escape any pointers.
So... more special cases?
> I think immovability is a red herring. The problem is a pointer is e
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #23 from Andrei Alexandrescu ---
(In reply to Tomer Filiba (weka) from comment #21)
> Walter, the @safe-ty aspects of the issue are one thing. In real code, @safe
> is hardly workable, i.e.
>
> void main() {
> int x;
> writeln(&x
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #22 from Tomer Filiba (weka) ---
void delegate() callback;
struct S {
int x;
@disable this(this);
this(int x) {
this.x = x;
callback = &inc;
}
void inc() {
x++;
}
}
auto f() {
return
https://issues.dlang.org/show_bug.cgi?id=17448
Tomer Filiba (weka) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
https://issues.dlang.org/show_bug.cgi?id=17448
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #19 from anonymous4 ---
(In reply to Andrei Alexandrescu from comment #14)
> LDC for example is very adept at
> "destructuring", i.e. exploding a struct into registers and "assembling" it
> back if necessary. Carrying the notion of "immov
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #18 from Walter Bright ---
(In reply to Walter Bright from comment #17)
> Another case:
>
> https://github.com/dlang/dmd/pull/6852
Also:
https://github.com/dlang/dmd/pull/6849
https://github.com/dlang/dmd/pull/6847
The three of them e
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #17 from Walter Bright ---
Another case:
https://github.com/dlang/dmd/pull/6852
--
https://issues.dlang.org/show_bug.cgi?id=17448
Stanislav Blinov changed:
What|Removed |Added
CC||stanislav.bli...@gmail.com
--- Comment #1
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #15 from Shachar Shemesh ---
(In reply to Andrei Alexandrescu from comment #14)
> * On the language definition side: the proposal would need to differentiate
> among (a) constructs that are guaranteed to not move; (b) operations that
> m
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #14 from Andrei Alexandrescu ---
(In reply to Eyal from comment #13)
> (In reply to Andrei Alexandrescu from comment #10)
>
> > Indeed, the spec should clarify under what circumstances objects can be
> > moved.
>
> Could we get compile-
https://issues.dlang.org/show_bug.cgi?id=17448
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #13 from Eyal ---
(In reply to Andrei Alexandrescu from comment #10)
> Indeed, the spec should clarify under what circumstances objects can be
> moved.
Could we get compile-time errors when we accidentally do something that moves a
stru
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #12 from Walter Bright ---
Interestingly, if you change:
auto f() {
return CallContext(18);
}
to:
auto f() {
CallContext c = CallContext(18);
return c;
}
it will work, i.e. no moving is done. This is because the co
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #11 from Walter Bright ---
One possibility is to not allow escaping references to 'this' in @safe
constructors.
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #10 from Andrei Alexandrescu ---
(In reply to Shachar Shemesh from comment #9)
> There are two issues here. The first is that @safe does not warn about
> unsafe behavior.
Affirmative.
> Interesting, but unrelated to the Weka use case.
>
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #9 from Shachar Shemesh ---
There are two issues here. The first is that @safe does not warn about unsafe
behavior. Interesting, but unrelated to the Weka use case.
The more interesting problem here is that certain types of programming a
https://issues.dlang.org/show_bug.cgi?id=17448
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@erdani.com
--- Comment #8 from
https://issues.dlang.org/show_bug.cgi?id=17448
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=17448
Walter Bright changed:
What|Removed |Added
Keywords||safe
CC|
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #7 from Tomer Filiba (weka) ---
it is obviously not a codegen issue, since i have a dangling pointer at hand.
it's just a matter of how the much stack the compiler requires. in LDC i
reproduce this by enlarging the tmp to 30 elements:
du
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #6 from b2.t...@gmx.com ---
It looks like a bad codegen and not a @safe issue. `ulong[20] tmp;` is not
corrupted if i compile and run your example with LDC2.
--
https://issues.dlang.org/show_bug.cgi?id=17448
Shachar Shemesh changed:
What|Removed |Added
CC||shac...@weka.io
--- Comment #5 from Shacha
https://issues.dlang.org/show_bug.cgi?id=17448
Eyal changed:
What|Removed |Added
CC||e...@weka.io
--- Comment #4 from Eyal ---
@uplink: W
https://issues.dlang.org/show_bug.cgi?id=17448
uplink.co...@googlemail.com changed:
What|Removed |Added
CC||uplink.co...@googlemail.com
---
https://issues.dlang.org/show_bug.cgi?id=17448
Tomer Filiba (weka) changed:
What|Removed |Added
CC||to...@weka.io
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #2 from Tomer Filiba (weka) ---
alternatively a move-operator is required
--
https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #1 from Tomer Filiba (weka) ---
I understand changing this might break backwards compatibility, but something
like a `pragma(dontmove);` in the struct is a must... that way it won't have
compiled, and we would pass it by ref instead of re
https://issues.dlang.org/show_bug.cgi?id=17448
Tomer Filiba (weka) changed:
What|Removed |Added
Keywords||industry
--
60 matches
Mail list logo
