On Wednesday, 16 October 2019 at 12:32:28 UTC, Paolo Invernizzi
wrote:
On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves
wrote:
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright
wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and
(maybe) deprecating the previous method is seen as
'annoying', also if it's a _clear_ improvement over the
actual situation (you can write _better_ code with that in
place compared to the actual situation, I mean)
@nogc doesn't actually enable writing better code. It doesn't
change the generated code at all.
I'm on the same boat with you, regarding what you wrote, but
... I still don't understand the number printed on the bar
level.
Atila is in charge of this, and he is because he's shown
excellent judgement about these matters over the years.
I think that I need to ruminate on Phobos v2.
In the meanwhile, a much easier and shorter route to improving
the D library ecosystem is to put something up on
code.dlang.org, which requires no gatekeeping.
While I agree on the ecosystem, the problem of keeping the
actual Phobos modules in a good shape still apply.
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. 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.
I understand that "there's always something else better for the
language to do", but Phobos is the current "home sweet home"
for everyone approaching D, and it's the first library
inspected in details.
I understand that and sympathise.
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>...
