On Monday, 7 October 2019 at 08:07:01 UTC, Joseph Rushton Wakeling wrote:
> Where's the breaking change? Are there selections of handlers that work for visit and don't work with match?

Yes.

https://run.dlang.io/is/UpaY2E

On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
> Phobos is amazing and stable, but exactly because of these attributes there isn't much active development happening.

I thought that the work on dip1000 and the current push for borrow semantics and other lifetime related issues that have certainly been receiving a lot of attention were partly motivated because Andrei could not write the containers library that he wanted to write, and that one of the first applications that those things would see is a proper containers library in Phobos.

On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote:
> On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
>> Well, so there's hope that _very little_ improvements will be merged, in a way or another? I mean, there's some sort of policy for things like that:
>> 
>>     https://github.com/dlang/phobos/pull/6730
>> 
>> Frankly speaking, the actual situation it's a little discouraging...
>
> We want a much higher bar for merging things than historically. A smaller, higher quality library is preferable to a kitchen sink library.

There is someone actively adding auto-merge labels to pull requests even when the pull request author specifically says the PR is not ready. So the bar has actually been lowered in recent times..

I'm not going to name names because it would be inappropriate, but people are beginning to notice.

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.

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 meant, writing better _source_ code, especially for reviewers.

>> 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'm faithful for Atila judgement, and at the same time I've always liked also your pragmatism. Anyway, I'll sit waiting for a policy decision on cases similar to the one mentioned.

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.

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 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.

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.

I've full faith in your and Walter judgement, of course.

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>...

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?

On Wednesday, 16 October 2019 at 15:23:01 UTC, Paolo Invernizzi wrote:
> On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves wrote:
>
>>> [...]
>>
>> 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"

Oh. I missed that.