www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Could someone take a look at DIP PR 109?

reply Shachar Shemesh <shachar weka.io> writes:
https://github.com/dlang/DIPs/pull/109

I submitted it 12 days ago. So far, except for two thumbs up, I got no 
official reaction of any kind for it.

I did get an unofficial list of suggestions from Andrei, which I have 
now incorporated into the DIP, but I was under the impression that I was 
supposed to either get rejects or a DIP number after a week. That has 
not happened so far.

For those too lazy to click on the link, the DIP is about adding ability 
to hook the implicit move D does with structs in order to update 
references (internal and/or external).

Shachar
Mar 27 2018
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh 
wrote:

 https://github.com/dlang/DIPs/pull/109

 I submitted it 12 days ago. So far, except for two thumbs up, I 
 got no official reaction of any kind for it.

 I did get an unofficial list of suggestions from Andrei, which 
 I have now incorporated into the DIP, but I was under the 
 impression that I was supposed to either get rejects or a DIP 
 number after a week. That has not happened so far.

 For those too lazy to click on the link, the DIP is about 
 adding ability to hook the implicit move D does with structs in 
 order to update references (internal and/or external).

 Shachar


Sorry, Shachar. I should have acknowledged it. I tend not to 
comment on DIPs unless I'm focusing on them at the moment. Right 
now, I'm working on the two just before yours in the queue and as 
soon as I move one of them forward I'll dig into yours.
Mar 27 2018
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh 
wrote:

 For those too lazy to click on the link,


BTW It's not the reader's 'laziness', it's basic courtesy on the 
part of the poster to the newsgroup to provide a meaningful 
subject line for a thread. Far more people will read the subject 
line than the person writing it. How is anyone supposed to 

repo)? People don't want to have to open every thread and scan 
for clues or click on links just to know if the thread is about 
something they find interesting.

(Don't take this rant personally, many people are guilty of not 
providing a good descriptive subject).

Thanks for writing the DIP though ;-)
Mar 28 2018
parent Shachar Shemesh <shachar weka.io> writes:
On 28/03/18 21:23, Nick Treleaven wrote:

 On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh wrote:

 For those too lazy to click on the link,


 
 BTW It's not the reader's 'laziness', it's basic courtesy on the part of 
 the poster to the newsgroup to provide a meaningful subject line for a 
 thread.


The subject of this thread was not "hey, I wrote a cool DIP, have a 
look". Had that been the case, I'd have your back 100%.

The subject was "I wrote a DIP and the steps that the procedure says 
should have happened have not".


 Thanks for writing the DIP though ;-)


You're welcome.

Shachar
Mar 28 2018
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh 
wrote:

 https://github.com/dlang/DIPs/pull/109

 I submitted it 12 days ago. So far, except for two thumbs up, I 
 got no official reaction of any kind for it.

 I did get an unofficial list of suggestions from Andrei, which 
 I have now incorporated into the DIP, but I was under the 
 impression that I was supposed to either get rejects or a DIP 
 number after a week. That has not happened so far.

 For those too lazy to click on the link, the DIP is about 
 adding ability to hook the implicit move D does with structs in 
 order to update references (internal and/or external).

 Shachar


Hi, simple question:

I wonder why the operator you want to add is not a member 
function ?
As far as i see (or as far i understand should i say) 
__move_post_blt would be a free function, right ?

It it's by necessity, there's probably something missing in your 
DIP.
Mar 29 2018
parent Shachar Shemesh <shachar weka.io> writes:
On 29/03/18 15:43, Basile B. wrote:

 
 Hi, simple question:
 
 I wonder why the operator you want to add is not a member function ?
 As far as i see (or as far i understand should i say) __move_post_blt 
 would be a free function, right ?
 
 It it's by necessity, there's probably something missing in your DIP.


__move_post_blt is just a compiler/run time library implementation 
detail. The important addition is opMove, which is a user defined 
function, and is a member.

My first draft actually did place __move_post_blt as a member of the 
struct. I quickly realized, however, that there is very little to gain 
and lots to lose. I'll try to list some of the reasons:

* Implicitly defined by the compiler

The function would be added to the struct by the compiler, whether you 
actually defined it or not. This opens a whole set of complications: do 
we return it when you enumerate the struct's methods? If so, we enter a 
minefield of backwards compatibility problems. If not, we're breaking 
promises.

* Little to gain by allowing overriding the default

The main reason to define it as part of the struct is to allow 
overriding the default behavior. The only advantage that would bring, 
however, is if you want to prevent the opMove of one of your members 
from running. I fail to see a use case for this.

Quite the contrary, I think opMove should prevent you from making stupid 
mistakes as much as possible. The first version of the PR actually had 
opMove's source reference be const, ensuring that you have a pristine 
copy to investigate if you so wish. Following some feedback from Andrei, 
I downgraded this to merely recommending it be const via the 
documentation, but not failing the compilation if you choose to keep it 
mutable.

If you provide me with cases where you think it makes sense for a 
containing struct to prevent the opMove defined in one of its members 
from running, we can have a more focused discussion.

Shachar
Mar 29 2018
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh 
wrote:

 https://github.com/dlang/DIPs/pull/109

 I submitted it 12 days ago. So far, except for two thumbs up, I 
 got no official reaction of any kind for it.

 I did get an unofficial list of suggestions from Andrei, which 
 I have now incorporated into the DIP, but I was under the 
 impression that I was supposed to either get rejects or a DIP 
 number after a week. That has not happened so far.

 For those too lazy to click on the link, the DIP is about 
 adding ability to hook the implicit move D does with structs in 
 order to update references (internal and/or external).

 Shachar


Good idea!

I've experimented with run-time variants [1] of Rust-style 
borrow-checking to detect range-invalidation in my containers but 
they can't handle moves because they don't use reference-counted 
storage. Having `opMove` will make it possible to forbid (via an 
`assert`) ranges from being invalidated when their associated 
container is about to moved so this is really a very good idea!

Alternatively the borrow-checking logic could be built into a 
reference-counted storage wrapper without the need for the 
potential use of `opMove` at the cost extra memory indirections.

[1] 
https://github.com/nordlow/phobos-next/blob/f64b94761325b68a52c361ffe36c95fc77c582c7/src/open_hashmap_or_hashset.d#L1308
Apr 02 2018