On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves wrote:
Please take a look at the cited pull request: it's a *trivial*
Phobos patch, that can be added aside to the current
implementation, blocked for months waiting for a _political_
decision.
I don't think it's political: the change implies breakage for
downstream users who inherit from the class who might not even
care about @nogc.
The proposed solution is to "add" a new @nogc method, with the
correct signature, so that if someone want to write application
and care about @nogc and @safe can rely on the D standard library
being complaint to that.
What's the problem with that, if not a _political_ one? We have a
"wrong" signature, we don't break anything, but we add "correct"
signature. That's what already was done in Mutex with
lock_nothrow, but it's seen as "annoying to have to define/use
alternate names for all the methods, though"
This a technical point. The easiest way out in my opinion is to
to inherit from it yourself and mark `receive` @nogc, as was
suggested in the PR.
That's can't be done without a cast, so we need to rely on
trusted, and we go again to the starting point, as stated the
pull request.
It's simply embarrassing to explain to an external reviewer
that a standard library method signature is inaccurate after
88 releases of version 2 of the language. And that yes,
'assumeNoGC' is needed, 'trust' that, and yes, an issue was
filed along with a potential fix.
Indeed. We're hardly alone in this: std::auto_ptr was/is an
embarassment in C++. Then there's std::vector<bool>...
And that's why I'm throwing a stone in the water: what's the
'concrete' procedures that the gatekeepers have in mind to
improve Phobos quality for cases like that?
Atila, that's really a _little_ change, if that can't be handled
easily, what about handling _big_ changes?
