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

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.

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 remember what PR #109 is (even if they do monitor the dlang/DIPs 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 ;-)

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

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.

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

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