On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:

@nogc code in Phobos still allows the use of the GC in client code. Those are not opposite goals.

No, that's not what that means. When Phobos was originally implemented, @nogc wasn't a thing. There was no (or little) consideration given to whether a particular function absolutely needed to use the GC, or if there was an alternative. And later on, as demand grew for more @nogc support, that had to be bolted on.

So what the @nogc as much as possible goal means is that it should be a consideration for the implementation of Phobos v2 from the beginning. The design of the API should allow @nogc client code to make use of it as much as possible.

GC is a strength, but it's not a panacea. There are specific cases where people determine it's better to avoid it, and there are some people who don't want to use it at all. As long as we continue to support @nogc in the language, then we ought to provide support for it in Phobos to the extent that we can. The vision document is just making it clear that this will be a goal from the beginning with v2.

On Monday, 4 July 2022 at 06:01:09 UTC, Mike Parker wrote:

Fair enough.

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:

Firstly, thank you for composing this.

Given the desire to reduce GC usage in PhobosV2, would it be fair to say this implies changing error handling schemes found therein, i.e. avoiding exceptions as they are implemented now, where reasonable? And if so, have core members mentioned any alternatives?

With regards to moderation policy, are there specific issues; about which you feel comfortable speaking; that prompted this item's inclusion in the vision document?

On Sunday, 3 July 2022 at 21:06:40 UTC, rikki cattermole wrote:

Yes, that is a common one that is maintained, but maybe there are BOOST licensed implementations too? One can do an exhaustive test for say two-character normalization against ICU to see if they are compliant.

Anyway, normalization should not happen behind your back in a system level language. You might want to treat different encodings of the same string differently when comparing.

I guess some Windows programmers want 16 bit… but I don't think the conversion matters all that much in that context?

The good reason would be that you can focus on fast SIMD optimized algoritms that makes sense for the byte-encoding of UTF-8, and get something competitive.

On Monday, 4 July 2022 at 07:28:23 UTC, StarCanopy wrote:

Walter and Atila have both talked about rethinking exceptions.

Atila brought it up in his DConf Online 2021 talk here:

https://youtu.be/UqW42_8kn0s?t=1429

You can see Walter's comments about it in the subsequent Q & A session here:

https://youtu.be/g26eJcs2QB0?t=1809

We've had a very, very lax moderation policy for years. Sometimes threads get derailed and posts become overly aggressive, but we've tended to let things slide as long as commenters avoid blatantly direct personal attacks, racist remarks, etc. I've always felt we have a great forum community compared to some others I've experienced, and I've found the need to delete forum posts, given the existing policy, to be relatively rare.

The flip side of that is that the larger internet community has evolved over the past couple of decades. What I consider tolerable if annoying behavior, others view as toxic. What I view as sarcasm or biting wit or some such, others view as personal attacks. We've received a number of complaints in recent months, directly and indirectly, about our forums being toxic. And that's not the image we want out there. And we definitely don't want people to actively choose not to participate in the forums just to avoid what they see as toxicity.

So we want to tighten the screws a little bit. In terms of directly deleting posts unprompted, the policy isn't changing. If I wouldn't have deleted a post before, I won't delete it now. What is changing is that we're going to be a bit more active in nudging threads back on topic when they stray too far off, and asking people to keep things toned down if their remarks become aggressive to the extent that it looks like they're going to derail the thread. We've had incidents in the past where one or two people upset a number of other forum users, and we didn't act as soon as we should have to keep things from getting out of hand.

In the past, forum users have sometimes reported posts to me indicating that they felt it was a direct personal attack. Usually, if I didn't see it as a direct attack, I wouldn't delete it. I'd explain how I see it and explain my reason for letting it stand. Going forward, I'll instead give a warning to the author of the post in question, and ask them to refrain from such remarks in future posts.

And once a warning is given (stay on topic, please tone it down, please avoid remarks like this one, etc.), any further posts in that thread that ignore the warning will be deleted.

I think that's a reasonable policy. The last thing any of us want is to stifle debate or censor opinions, but we feel that it's reasonable to ask people to participate in debates and express their opinions without upsetting others. So we're going to do our best to find a middle ground.

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:

In the document it is said:

I think this should be extended to clarify how conversion to @nogc will be tackled. IMHO adding proper stable @nogc allocators to the stdlib is more important.

When that's done, make sure we can set the allocator for stdlib types and add @nogc overloads that take an allocator parameter for non-@nogc functions.

We aren't doing no-heap programming after all. If we have a stable allocator interface, replacing GC calls with allocator calls in Phobos shouldn't be too hard.

On Monday, 4 July 2022 at 16:12:35 UTC, rikki cattermole wrote:

Argh, linking to large files...

Well, you also have to test for the cases that should not trigger any change, and also for sequencing/parsing bugs. So, not complete, but a good start.