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 <[email protected]> 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++. >
