Re: The D Programming Language Vision Document
On 04/07/2022 7:39 PM, Ola Fosheim Grøstad 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. https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt My implementation passes this :3 It should be complete test cases.
Re: The D Programming Language Vision Document
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: You can find the final draft of the high-level goals for the D programming language at the following link: https://github.com/dlang/vision-document I also want to reiterate that this is a living document. We will modify the goals as needed as time goes by. Feedback is welcome. In the document it is said: `@nogc` as much as possible. 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.
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 07:28:23 UTC, StarCanopy wrote: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: [...] 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? 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 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? 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.
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 05:51:48 UTC, Andrej Mitrovic wrote: On Monday, 4 July 2022 at 05:35:20 UTC, rikki cattermole wrote: On 04/07/2022 5:30 PM, Andrej Mitrovic wrote: Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. Not necessarily. It could and should most likely mean that it won't do any heap allocations. Heap allocations are expensive after all. @safe @nogc @noheap? :) @noheap is not so necessary, at least for aggregates we have `@disable new(size_t);`
Re: The D Programming Language Vision Document
On Sunday, 3 July 2022 at 21:06:40 UTC, rikki cattermole wrote: We have a perfectly good Unicode handling library already. (Okay, little out of date and doesn't handle Turkic stuff, but fixable). The standard one is called ICU. 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. Anyway, we are straying from my original point, that limiting ourselves to the string alias and not supporting wstring or dstring in Phobos is going to bite us. I guess some Windows programmers want 16 bit… but I don't think the conversion matters all that much in that context? There better be a good reason for this that isn't just removing templates. 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.
Re: The D Programming Language Vision Document
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?
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 06:01:09 UTC, Mike Parker wrote: 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. Fair enough.
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: You can find the final draft of the high-level goals for the D programming language at the following link: https://github.com/dlang/vision-document Under 'Memory safety': Allow the continued use of garbage collection as the default memory management strategy without impact. The GC is one of D's strengths, and we should not "throw the baby out with the bath water". Under 'Phobos and DRuntime': @nogc as much as possible. Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. `@nogc` code in Phobos still allows the use of the GC in client code. Those are not opposite goals. Then it's not part of D's strengths. 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.
