What's the go with the GC these days?

[Manu]

On Sat, Jan 5, 2019 at 10:55 PM Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 1/5/2019 8:52 PM, Neia Neutuladh wrote:
> > The only other way I know of to implement a write barrier is to insert
> > some code on every pointer write. GC-as-a-library would require you to use
> > their pointer type instead of the builtin, and I expect most C++ devs
> > would rather just use a reference counting pointer type instead.
>
> Microsoft tried this with their "Managed C++" variant of C++, where they had two
> fundamental pointer types. It was a laudable effort, but failed to gain
> traction. D learns from that mistake :-)

I was very much 'there' when this was rejected by the community. I
don't think it 'failed to gain traction' despite trying, so much as it
was just plain rejected or dismissed.
And not for any particularly good reason. It went like this among the
~hundreds of programmers I interacted with at the time.
1. "Managed C++" is code for "lame C#", or just "C# interop layer"
2. C++ users want absolutely nothing to do with C#, and nothing to do
with the word 'managed'
3. C# users want absolutely nothing to do with C++
4. The feature didn't stand alone as a C++ feature
5. Even if it did, it was limited to windows, and to MS compilers.
Completely not-portable.

It's obvious why it failed. I don't think comment on the merit of the
design has any relevance at all to that particular story.
The particulars of the design and whether it was good or not couldn't
have had less affect on the feature being ignored and/or rejected.

> > Either the speed has improved, or they're just eating the time cost.
>
> The fact that Java/Go/etc. use inserted write gates suggest the speed hasn't
> improved, which leaves eating the cost.

Could D insert such code, and also effectively elide it where @nogc is
used (or inferred)?
If we can help the GC in common code, but still have the expressive
power we need to elide that extra work where we know it's not
necessary, then it might be reasonable to consider.