So I have another upcoming opportunity to introduce D in my workplace, this time as a front-end/plugin language to our C++ infrastructure, which is promising since I already have considerable experience in this area (my work at Remedy with Quantum Break), and there is a lot of recent work to interact better with C++, which we will stress-test extensively.

You only get so many shots at this; but this is a particularly promising opportunity, since the C++ code is a nightmare, and the contrast against D will allow a lot of coders to see the advantage.

There is however one critical missing feature, DIP74... where is it at currently? How is it going? Is it likely to be accepted in the near-term? Some sort of approximate timeline?

I think it would be a mistake for me to introduce this without DIP74, since we will rely on it VERY heavily, and the machinery to work-around it will start to look just as heavy-weight as the C++ code I'm trying to deprecate... but then waiting on it starts to look like missing the window of opportunity.

Thoughts?

On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
> So I have another upcoming opportunity to introduce D in my workplace, this time as a front-end/plugin language to our C++ infrastructure, which is promising since I already have considerable experience in this area (my work at Remedy with Quantum Break), and there is a lot of recent work to interact better with C++, which we will stress-test extensively.
>
> You only get so many shots at this; but this is a particularly promising opportunity, since the C++ code is a nightmare, and the contrast against D will allow a lot of coders to see the advantage.
>
> There is however one critical missing feature, DIP74... where is it at currently? How is it going? Is it likely to be accepted in the near-term? Some sort of approximate timeline?
>
> I think it would be a mistake for me to introduce this without DIP74, since we will rely on it VERY heavily, and the machinery to work-around it will start to look just as heavy-weight as the C++ code I'm trying to deprecate... but then waiting on it starts to look like missing the window of opportunity.
>
> Thoughts?

It doesn't looks like it is getting implemented. And, to be honest, I'd rather go a principle approach + library support rather than a pie of hacks.

The pile of hacks approach is what made C++ C++.

I'm rather in favour of DIP74... what's unprincipled about it? What would you do instead?

On 11 October 2015 at 10:20, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
>>
>> So I have another upcoming opportunity to introduce D in my workplace,
>> this time as a front-end/plugin language to our C++ infrastructure, which is
>> promising since I already have considerable experience in this area (my work
>> at Remedy with Quantum Break), and there is a lot of recent work to interact
>> better with C++, which we will stress-test extensively.
>>
>> You only get so many shots at this; but this is a particularly promising opportunity, since the C++ code is a nightmare, and the contrast against D will allow a lot of coders to see the advantage.
>>
>> There is however one critical missing feature, DIP74... where is it at currently? How is it going? Is it likely to be accepted in the near-term? Some sort of approximate timeline?
>>
>> I think it would be a mistake for me to introduce this without DIP74, since we will rely on it VERY heavily, and the machinery to work-around it will start to look just as heavy-weight as the C++ code I'm trying to deprecate... but then waiting on it starts to look like missing the window of opportunity.
>>
>> Thoughts?
>
>
> It doesn't looks like it is getting implemented. And, to be honest, I'd rather go a principle approach + library support rather than a pie of hacks.
>
> The pile of hacks approach is what made C++ C++.
>

On Sunday, 11 October 2015 at 00:20:08 UTC, deadalnix wrote:
> It doesn't looks like it is getting implemented. And, to be honest, I'd rather go a principle approach + library support rather than a pie of hacks.
>
> The pile of hacks approach is what made C++ C++.

AFAIK, Walter and Andrei are still in favor of something that's at least similar to DIP 74. Andrei made a comment in a thread just the other day that indicated that he was in favor of having a way to build reference counting into classes. So, I don't know why you think that it's not going to be implemented other than the fact that it hasn't been implemented yet. It wouldn't surprise me if the DIP needed some tweaking though.

Regardless, now is not the best time to ask this sort of question, because Walter and Andrei are on their trip to Romania, and they're going to have a limited presence in the newsgroup at the moment.

It wouldn't surprise me though if something like the possibility of getting D into another company relied on something like DIP 74 helped push it along and got it sorted out faster. Clearly, Walter and Andrei think that it's an issue and have done some work on it at the theoretical level, but I don't know where it sits on their priority list. And even if DIP 74 were fully sorted out tomorrow, it would still require Walter or someone else actually implementing it, and that's probably not a small undertaking.

- Jonathan M Davis

On Sunday, 11 October 2015 at 01:48:05 UTC, Manu wrote:
> I'm rather in favour of DIP74... what's unprincipled about it? What would you do instead?
>

Well, DIP25 and DIP74 are ad hoc adding to the language to support specific use cases. I think the whole thing is wrong headed.

Ideally when designing the language you want to have a set of principled tools added to the language that enable the uses cases you want. You don't bake the uses cases into the language. Inevitably, new use cases crop up, they get poor support and/or ends up as new addition into the language, with more and more complexity along the road.

The problem at hand is fairly well know at this stage: it is ownership. Everything else can be done as library.

The DIP25/DIP74 combo is quite limited. It doesn't solve ownership transfer, it forces an ownership model on the user, it doesn't reduce friction with the GC, it doesn't allow to delegate memory management to the user (the only kind that make sense). and worse, as these issue aren't orthogonal to these DIP, they actively make these problem harder to solve.

Solution have been proposed to solve these. It is not hardly new. I mean C++ obviously got the hint: https://github.com/isocpp/CppCoreGuidelines/blob/09aef9bd86d933bc1e1ffe344eb2e73d2de15685/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf

If we go these DIP road, there is no coming back and this will get in the way of a principled approach.

On Sunday, 11 October 2015 at 02:01:09 UTC, Jonathan M Davis wrote:
> AFAIK, Walter and Andrei are still in favor of something that's at least similar to DIP 74. Andrei made a comment in a thread just the other day that indicated that he was in favor of having a way to build reference counting into classes. So, I don't know why you think that it's not going to be implemented other than the fact that it hasn't been implemented yet. It wouldn't surprise me if the DIP needed some tweaking though.
>

Yes, and that's quite ridiculous. I mean this is getting into ridiculous ego battle. Remind of that concept vs static if grand debate, the peak of ridiculousness (everybody know you don't need type system when you have if statement and vice versa, so the same must be true at compile time as well).

When a direction obviously showed to be the wrong one, the rational thing to do is not to double down in order to not admit one is wrong.

DIP25 implementation showed a ton of limitations and pitfalls. It isn't even possible to do a slice type with eager deallocation, just one with deferred deallocation, with complex strategies to make it all safe.

It is a sign of a poorly thought out language addition.

> It wouldn't surprise me though if something like the possibility of getting D into another company relied on something like DIP 74 helped push it along and got it sorted out faster. Clearly, Walter and Andrei think that it's an issue and have done some work on it at the theoretical level, but I don't know where it sits on their priority list. And even if DIP 74 were fully sorted out tomorrow, it would still require Walter or someone else actually implementing it, and that's probably not a small undertaking.
>
> - Jonathan M Davis

Yeah, we saw what happens with attributes. Don't get me wrong, attribute are a very useful addition to the language and all, but the current implementation has some serious flaws, none of them could be addressed as it was pushed out of the door in an inconsequent manner. The fact that dlang.org is littered of antipaterns usage of them is quite telling.

I'm all for pushing useful feature, especially if that can drive adoption in a company. But using it as an excuse for releasing half backed feature is VERY short sighted.

On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
> If we go these DIP road, there is no coming back and this will get in the way of a principled approach.

Then come up with an alternative DIP which shows a better way to solve this. As it stands, it looks likely that we'll end up with some form of DIP 74, and if you have a better proposal, then now is probably the time to do it.

Personally, I obviously haven't been following this closely enough, because I don't understand why something like RefCounted can't be made to do what we need with regards to reference counting and classes. It does get a bit nasty when inheritance and whatnot get involved, but C++ was able to solve that easily enough, and we should be able to do the same.

The one place in-language where I'm sure that something like RefCounted doesn't do it is exceptions, since we really should have a way to make those reference counted, but you can only throw something derived from Throwable - which means a class and not a wrapper around one. So, we need a tweak of some kind to the language there, but that's pretty specific, whereas it _should_ be possible to get something like RefCounted to at least solve the normal cases. Clearly though, Walter and Andrei have come to the conclusion that it's not.

- Jonathan M Davis

On Sunday, 11 October 2015 at 04:35:03 UTC, Jonathan M Davis wrote:
> On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
>> If we go these DIP road, there is no coming back and this will get in the way of a principled approach.
>
> Then come up with an alternative DIP which shows a better way to solve this. As it stands, it looks likely that we'll end up with some form of DIP 74, and if you have a better proposal, then now is probably the time to do it.
>

I have, other have as well, in fact there was a lengthy discussion in private between Walter, Andrei, myself and some other where very precise proposal has been made.

I'm sorry but that's bullshit. I'm tired of reexplaining the same thing again and again while is it clear that nobody cares about facts here. If people would care about facts, the DIP25 fiasco would have been enough to put the ideas back on the table.

> The one place in-language where I'm sure that something like RefCounted doesn't do it is exceptions, since we really should have a way to make those reference counted, but you can only throw something derived from Throwable - which means a class and not a wrapper around one. So, we need a tweak of some kind to the language there, but that's pretty specific, whereas it _should_ be possible to get something like RefCounted to at least solve the normal cases. Clearly though, Walter and Andrei have come to the conclusion that it's not.
>

Proposal included solution for this problem. Exception ownerhip is transferred to the runtime when thrown, and the runtime transfer it back to the catch block that effectively catches it.

On Sunday, 11 October 2015 at 04:56:25 UTC, deadalnix wrote:
> On Sunday, 11 October 2015 at 04:35:03 UTC, Jonathan M Davis wrote:
>> On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
>>> If we go these DIP road, there is no coming back and this will get in the way of a principled approach.
>>
>> Then come up with an alternative DIP which shows a better way to solve this. As it stands, it looks likely that we'll end up with some form of DIP 74, and if you have a better proposal, then now is probably the time to do it.
>>
>
> I have, other have as well, in fact there was a lengthy discussion in private between Walter, Andrei, myself and some other where very precise proposal has been made.
>
> I'm sorry but that's bullshit. I'm tired of reexplaining the same thing again and again while is it clear that nobody cares about facts here. If people would care about facts, the DIP25 fiasco would have been enough to put the ideas back on the table.

Well, if they won't listen, they won't listen. And if they're wrong, we'll be worse off for it. Unfortunately, I wasn't involved in those discussions and haven't looked into DIP 25 much (I was too busy at the time of the major discussion for it IIRC). So, I'm not familiar enough with it to have a properly informed opinion. But convincing Walter and Andrei is typically pretty difficult. They do come around eventually at least some of the time though. So, as frustrating as such discussions can be, they do bear fruit at least some of the time (whether it's by them convincing you or by you convincing them). And since DIP 25 has only been implemented with a flag rather than adding it to the language proper yet, there's still time to convince them before we're fully committed to it - as difficult as convincing them may be.

- Jonathan M Davis

On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
> The problem at hand is fairly well know at this stage: it is ownership. Everything else can be done as library.

This.