lling convention.
Which is, however, not a reason to formalize it and make it a
requirement for an isolated specific case, such as this one,
utilizing a syntax that is currently not used by the language.
There is positively nothing in DIP 1014 that is "syntax not
used by the language". Qui
specify in the language. Why?
Which is, however, not a reason to formalize it and make it a
requirement for an isolated specific case, such as this one, utilizing a
syntax that is currently not used by the language.
There is positively nothing in DIP 1014 that is "syntax not used by the
n the first place.
So to get that to work, you'd need to insert a special case
into the ABI of the language: if the function's name is
someName, treat it differently.
Yes, that's what I'm talking about.
At this point, you might as well call a spade a spade, and just
giv
unction's name is someName, treat it differently.
At this point, you might as well call a spade a spade, and just give the
function that signature explicitly. s/someName/opPostMove/, and you get
DIP 1014 (as far as point #2 is concerned).
Shachar
On Thursday, 4 October 2018 at 08:10:31 UTC, Shachar Shemesh
wrote:
On 04/10/18 11:05, Stanislav Blinov wrote:
On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh
wrote:
[...]
For the love of Pete, that program was an example of how a
move hook should work, *not* a demonstration o
On 04/10/18 11:05, Stanislav Blinov wrote:
On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote:
If you do *anything* to that program, and that includes even changing
its compilation flags (try enabling inlining), it will stop working.
You should have known that when you found o
On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh
wrote:
If you do *anything* to that program, and that includes even
changing its compilation flags (try enabling inlining), it will
stop working.
You should have known that when you found out it doesn't work
on ldc: ldc and dmd us
On Wed, Oct 3, 2018 at 11:00 PM Timothee Cour via Digitalmars-d
wrote:
>
> @Manu, @Jonathan M Davis
>
> > GNU's std::string implementation stores an interior pointer! >_<
>
> it's not just GNU's std::string ; it can crop up in other places, see
> https://github.com/Syniurge/Calypso/issues/70 in op
@Manu, @Jonathan M Davis
> GNU's std::string implementation stores an interior pointer! >_<
it's not just GNU's std::string ; it can crop up in other places, see
https://github.com/Syniurge/Calypso/issues/70 in opencv (cv:: MatStep)
On Wed, Oct 3, 2018 at 8:10 PM Shachar Shemesh via Digitalmars
On 03/10/18 23:25, Stanislav Blinov wrote:
It *is* true when the type doesn't have a destructor. Extending that to
a move hook, it will also be true because destruction will be elided.
I know what you're talking about, that happens for types that have
destructors.
No, destructors have nothing
On Wednesday, 3 October 2018 at 18:58:37 UTC, Shachar Shemesh
wrote:
On 03/10/18 20:43, Stanislav Blinov wrote:
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh
wrote:
I.e. - I am asserting if a move was not caught. The program
fails to run on either ldc or dmd. To me, this makes
On Wednesday, 3 October 2018 at 18:38:50 UTC, Manu wrote:
On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via
Digitalmars-d wrote:
Any function in D that has a signature of the form
ReturnType foo(Type x);
in C++ would have an equivalent signature of
ReturnType foo(Type&& x); // NOT Return
On 03/10/18 20:43, Stanislav Blinov wrote:
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote:
I.e. - I am asserting if a move was not caught. The program fails to
run on either ldc or dmd. To me, this makes perfect sense as for the
way D is built. In essence, opAssign isn't
On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> Shachar, as I don't see a better place of discussing that DIP at
> the moment, I'll pour some observations and thoughts in here if
> you don't mind, will add some comments on GitHub later.
> As I see it right now, it's a
On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote:
Okay, so copy elision is working... but moves otherwise are
not? That's still not what we've been peddling all these years.
A whole lot of design surface area is dedicated to implicit
move semantics... and they don't work? What does it
On Wednesday, 3 October 2018 at 17:43:08 UTC, Stanislav Blinov
wrote:
But IMHO, it's something that should be fixed by not making
these facilities built into the language.
s/not//
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh
wrote:
On 03/10/18 17:29, Stanislav Blinov wrote:
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
Yes. I am actually sorry about that. I was respon
On 03/10/18 12:48, Corel wrote:
The fact that in D the structures to date are not moved, is known for
years ... take advantage of this fact, and move on.
I have no idea where you got this fact:
import std.stdio;
struct MoveTest {
static uint counter=1;
uint id;
@disable this(this
On Wed, Oct 3, 2018 at 2:50 AM Corel via Digitalmars-d
wrote:
>
> On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote:
> > On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d
> > wrote:
> >>
> >> On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
> >> > On Tuesday, 2 October 2018 at 22:30
On 03/10/18 18:33, Shachar Shemesh wrote:
~this() {
writefln("%s destructed", &this);
assert(counter is null || counter is &localCounter);
}
You might also want to add @disable this(this); and remove the dead code
(i.e. - the case where the pointer is global) to re
On 03/10/18 17:29, Stanislav Blinov wrote:
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
Yes. I am actually sorry about that. I was responding to your assumption
that I'm wrong. Had your post been phrased as
On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
If you read the DIP, you will notice that the *address* in
which the old instance resides is quite important...
Allow me to further illustrate with something that can be written
in D today:
import std.stdio;
struct Track
On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
And this simply an
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
And this simply and utterly doesn't work.
If you read the DIP, you will notice that the *address* in which the old
instance resides is quite important f
On Wednesday, 3 October 2018 at 13:56:29 UTC, Stanislav Blinov
wrote:
Aendment, this should of course be:
this(Tracker oldLocation) {
localCounter = oldLocation.locaclCounter;
counter = oldLocation.counter;
if( counter is &oldLocation.localCounter )
coun
Shachar, as I don't see a better place of discussing that DIP at
the moment, I'll pour some observations and thoughts in here if
you don't mind, will add some comments on GitHub later.
As I see it right now, it's a case of over-engineering of a quite
simple concept.
1. A new function, called _
On 03/10/18 04:10, Walter Bright wrote:
On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote:
Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler
moved structs in a number of situations - e.g. when the return value
was an rv
On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote:
On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d
wrote:
On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
> On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis
> wrote:
>> Yeah. IIRC, it was supposed to be _guaranteed_
On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d
wrote:
>
> On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
> > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote:
> >> Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved
> >> structs
> >> in a number of
On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote:
Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved structs
in a number of situations - e.g. when the return value was an rvalue.
Something like
Eh, I don't think
On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis
wrote:
Yeah. IIRC, it was supposed to be _guaranteed_ that the
compiler moved structs in a number of situations - e.g. when
the return value was an rvalue. Something like
Eh, I don't think that moves it, but rather just constructs it
uct attribute that means "not moveable"
> > > 3. DIP 1014, which is add a __move_post_blit() function (most complex
> > > solution) 4. Use copy/destruct for C++ structs that have copy
> > > constructors (this is the old C++ solution, and is less efficient
>
On 10/2/18 1:51 PM, Manu wrote:
But dangling pointer is an instant crash/memory corruption... it's a
pretty bad 'bug'.
Yeah doesn't sound very brilliant. I think such a workaround wouldn't
fare well. To keep momentum while we mull over a solution to this I
suggest you look at porting other da
On Tue, Oct 2, 2018 at 2:40 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/2/2018 2:17 AM, Walter Bright wrote:
> > 1. Don't allow moving of C++ structs
> > 2. Add a struct attribute that means "not moveable"
> > 3. DIP 1014, which is add a __
On Tue, Oct 2, 2018 at 2:20 AM Walter Bright via Digitalmars-d
wrote:
>
> On 9/29/2018 9:34 PM, Manu wrote:
> > Who knows about DIP 1014? (struct move hook)
> > Is it well received? Is it likely to be accepted soon?
> >
> > I'm working on the std::string b
On 10/2/2018 2:17 AM, Walter Bright wrote:
1. Don't allow moving of C++ structs
2. Add a struct attribute that means "not moveable"
3. DIP 1014, which is add a __move_post_blit() function (most complex solution)
4. Use copy/destruct for C++ structs that have copy constructors (thi
On 9/29/2018 9:34 PM, Manu wrote:
Who knows about DIP 1014? (struct move hook)
Is it well received? Is it likely to be accepted soon?
I'm working on the std::string binding, it's almost finished... but
then I hit a brick wall.
GNU's std::string implementation stores an i
On 9/29/2018 9:34 PM, Manu wrote:
Who knows about DIP 1014? (struct move hook)
When discussing DIP 1014, a link is helpful:
https://github.com/dlang/DIPs/blob/38cec74a7471735559e3b8a7553f55102d289d28/DIPs/DIP1014.md
On Sunday, September 30, 2018 1:35:28 AM MDT Shachar Shemesh via
Digitalmars-d wrote:
> On 30/09/18 10:26, Manu wrote:
> > Other implementations make much better use of that built-in space by
> > not wasting 8 bytes on an interior pointer for small-strings.
>
> I will point out that a pointer that
On 30/09/18 10:26, Manu wrote:
Other implementations make much better use of that built-in space by
not wasting 8 bytes on an interior pointer for small-strings.
I will point out that a pointer that *sometimes* points to an internal
member was one of the use cases I documented when I submitt
On Sat, Sep 29, 2018 at 11:50 PM Walter Bright via Digitalmars-d
wrote:
>
> On 9/29/2018 9:34 PM, Manu wrote:
> > GNU's std::string implementation stores an interior pointer! >_<
> >
> > No other implementation does this. It's a really bad implementation
> > actually, quite inefficient. It could m
On 9/29/2018 9:34 PM, Manu wrote:
GNU's std::string implementation stores an interior pointer! >_<
No other implementation does this. It's a really bad implementation
actually, quite inefficient. It could make better use of its space for
small-strings if it wasn't wasting 8-bytes for an interior
On Saturday, September 29, 2018 10:34:20 PM MDT Manu via Digitalmars-d
wrote:
> Who knows about DIP 1014? (struct move hook)
> Is it well received? Is it likely to be accepted soon?
>
> I'm working on the std::string binding, it's almost finished... but
> then I hit
On Sunday, 30 September 2018 at 04:34:20 UTC, Manu wrote:
Who knows about DIP 1014? (struct move hook)
Is it well received? Is it likely to be accepted soon?
I'm working on the std::string binding, it's almost finished...
but
then I hit a brick wall.
GNU's std::string implement
Who knows about DIP 1014? (struct move hook)
Is it well received? Is it likely to be accepted soon?
I'm working on the std::string binding, it's almost finished... but
then I hit a brick wall.
GNU's std::string implementation stores an interior pointer! >_<
No other imp
On 17/07/18 16:29, aliak00 wrote:
A postblit on a class issues a compiler error. And an identity opAssign
on a class also issues a compiler error. So I'm not sure how this would
be different. And the page In
https://dlang.org/spec/operatoroverloading.html also explicitly mentions
differences
On Thursday, 12 July 2018 at 10:24:40 UTC, Shachar Shemesh wrote:
On 29/06/18 15:35, aliak wrote:
On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
Thanks in advance for your participation.
For those of you using th
but I'm not sure.
Either way, the current language spec says structs must have semantics
that remain correct even if the struct suddenly changes the memory
address it resides in. The specs + DIP 1014 say that the above is true,
or the struct must supply an opPostMove that fixes the semanti
On Thursday, 12 July 2018 at 10:22:33 UTC, Shachar Shemesh wrote:
On 11/07/18 20:04, Johan Engelen wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready
for final review.
after quick read:
(would be
On Thursday, 12 July 2018 at 10:38:52 UTC, Shachar Shemesh wrote:
On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure
if going to copy constructors means that we should do
something> different with this. It don't think that it's
affected by it, but I could be> missing something.
I
On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure if going
to copy constructors means that we should do something> different with
this. It don't think that it's affected by it, but I could be> missing
something.
I actually had that very same concern myself. Andrei does not seem to
On 29/06/18 15:35, aliak wrote:
On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
Thanks in advance for your participation.
For those of you using the NNTP or mailing list interfaces, this is
the thread to respond i
On 11/07/18 20:04, Johan Engelen wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready for final
review.
after quick read:
(would be much easier to do inline commenting, but it appears that&#
On Wednesday, 27 June 2018 01:13:14 MDT Mike Parker via Digitalmars-d wrote:
> DIP 1014, "Hooking D's struct move semantics", is now ready for
> final review. This is a last chance for community feedback before
> the DIP is handed off to Walter and Andrei for the Formal
&
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready for
final review.
after quick read:
(would be much easier to do inline commenting, but it appears
that's not supported)
### Section "Code e
On Thursday, 5 July 2018 at 10:27:52 UTC, Dukc wrote:
The DIP looks well written. I'm in favour of it.
However, we need to consider how well this interacts with
Razvan's DIP [1]. We should consider this together with it, so
the implementations do not end up messing each other.
1:
https://f
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready for
final review.
Structs are a low level feature that should be able to be used in
any way programmer sees fit. This is just what is wrong with C#
struct
On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
Thanks in advance for your participation.
For those of you using the NNTP or mailing list interfaces,
this is the thread to respond in. Thanks!
Alo!
This is great!
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
Thanks in advance for your participation.
For those of you using the NNTP or mailing list interfaces, this
is the thread to respond in. Thanks!
DIP 1014, "Hooking D's struct move semantics", is now ready for
final review. This is a last chance for community feedback before
the DIP is handed off to Walter and Andrei for the Formal
Assessment. Please read the procedures document for details on
what is expected in th
DIP 1014, "Hooking D's struct move semantics", is now ready for
final review. This is a last chance for community feedback before
the DIP is handed off to Walter and Andrei for the Formal
Assessment. Please read the procedures document for details on
what is expected in th
On 18/05/18 22:57, kinke wrote:
I checked, and the reason is that D and C++ use a different ABI wrt.
by-value passing of non-POD arguments. C++ indeed passes a reference to
a caller-allocated rvalue, not just on Win64; that makes it trivial, as
there are no moves across call boundaries. But you
believe that an IR representation of DIP 1014
is possible.
I checked, and the reason is that D and C++ use a different ABI
wrt. by-value passing of non-POD arguments. C++ indeed passes a
reference to a caller-allocated rvalue, not just on Win64; that
makes it trivial, as there are no moves
On Thursday, 17 May 2018 at 20:25:26 UTC, Shachar Shemesh wrote:
Obviously, Something can be an enum or a boolean. If it is,
however, then we have to perform a condition to select the
correct value. The problem with conditionals is that if the CPU
misses a guess about what they are (and in our
On Thursday, 17 May 2018 at 19:13:48 UTC, Shachar Shemesh wrote:
The only inherent non @safe thing we advocate here is if you
want to be able to move const/immutable structs, in which case
DIP 1014 advocates casting the constness away. That will, of
course, have to be either @system or
On 17 May 2018 at 13:25, Shachar Shemesh via Digitalmars-d
wrote:
> On 17/05/18 22:29, Manu wrote:
>>
>>
>> This is great!
>> I've wanted this on numerous occasions when interacting with C++ code.
>> This will make interaction more complete.
>>
>> Within self-contained D code, I have avoided self-
On 17/05/18 22:29, Manu wrote:
This is great!
I've wanted this on numerous occasions when interacting with C++ code.
This will make interaction more complete.
Within self-contained D code, I have avoided self-pointers by using
self-offsets instead in the past (a bit hack-ey). But this nicely
ti
On 17 May 2018 at 01:12, Mike Parker via Digitalmars-d
wrote:
> This is the review thread for the first Community Review round for DIP 1014,
> "Hooking D's struct move semantics".
>
> All review-related feedback on and discussion of the DIP should occur in
> this
de.
With that said, just because the code is not safe, does not mean it is
not @safe.
The only inherent non @safe thing we advocate here is if you want to be
able to move const/immutable structs, in which case DIP 1014 advocates
casting the constness away. That will, of course, have to b
constructor
}
Since clang is able to compile this struct and do everything with it,
and since the existence of the move constructor requires the precise
same type of hooking as is needed in this case, I tend to believe that
an IR representation of DIP 1014 is possible.
Shachar
On Thursday, 17 May 2018 at 13:50:26 UTC, Shachar Shemesh wrote:
There is no such use case. Please remember that at the time
opPostMove is called, both new and old memory are still
allocated.
That's an interesting moment too. A struct that was supposed to
be moved is copied instead and exists
On Thursday, 17 May 2018 at 15:23:50 UTC, kinke wrote:
See IR for https://run.dlang.io/is/1JIsk7.
I should probably emphasize that the LLVM `byval` attribute is
strange at first sight. Pseudo-IR `void foo(S* byval param); ...
foo(S* byarg arg);` doesn't mean that the IR callee gets the S*
po
On Thursday, 17 May 2018 at 12:36:29 UTC, Shachar Shemesh wrote:
Again, as far as I know, structs are not copied when passed as
arguments. They are allocated on the caller's stack and a
reference is passed to the callee. If that's the case, no move
(of any kind) is done.
That's the exception
On 17/05/18 16:42, Kagamin wrote:
Looks like requirement for @nogc @safe has no consequence as the DIP
suggests to infer them anyway. On ideological side safety can't be a
requirement because it would contradict its purpose of providing
guarantee.
I think you are confusing __move_post_blt's i
Looks like requirement for @nogc @safe has no consequence as the
DIP suggests to infer them anyway. On ideological side safety
can't be a requirement because it would contradict its purpose of
providing guarantee. Especially if the suggested use case is
handling of dangling pointers.
I'm not sure I follow all of your comments.
For the rest my comments, let's assume that the compiler may assume that
__move_post_blt is a no-op if hasElaborateMove returns false.
On 17/05/18 14:33, kinke wrote:
3. When deciding to move a struct instance, the compiler MUST emit a
call to the s
3. When deciding to move a struct instance, the compiler MUST
emit a call to the struct's __move_post_blt after blitting the
instance and before releasing the memory containing the old
instance. __move_post_blt MUST receive references to both the
pre- and post-move instances.
This implies tha
On 17/05/18 11:22, rikki cattermole wrote:
What is the benefit of opPostMove over copy constructors (not postblit)?
The two are unrelated. A copy is a very different operation from a move.
With a copy, you have to figure out how to duplicate the resources used
by the object. With a move, no
On 17/05/2018 8:12 PM, Mike Parker wrote:
This is the review thread for the first Community Review round for DIP
1014, "Hooking D's struct move semantics".
All review-related feedback on and discussion of the DIP should occur in
this thread. The review period will end at 11:59
This is the review thread for the first Community Review round
for DIP 1014, "Hooking D's struct move semantics".
All review-related feedback on and discussion of the DIP should
occur in this thread. The review period will end at 11:59 PM ET
on May 31, or when I make a po
On Thursday, 17 May 2018 at 08:12:50 UTC, Mike Parker wrote:
This is the review thread for the first Community Review round
for DIP 1014, "Hooking D's struct move semantics".
And the link to the DIP:
https://github.com/dlang/DIPs/blob/38cec74a7471735559e3b8a7553f55102d289d28/DIPs/DIP1014.md
81 matches
Mail list logo
