In my blog this week, I described an idea I've had percolating in my brain for a bit about a user-defined effect system that could potentially move nogc, safe, pure, etc to library aliases - which would let you combine them as a fun bonus - among other things:

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_15.html

Like with other inferred attributes, the argument-dependent and virtual function caveats had to be mentioned, but since I talked about them in other posts not too long ago I didn't want to go over it all again.

Next week, I'll probably write up release notes on arsd 10.9, which is overdue now but has a few new features (including ico file support, more http timeout control, a couple more hidpi linux fixes, a windows input gui fix, data uri transparent support, terminal cursor save/restore, and others) I'll tag once I finish regression testing. I doubt I'll announce that here since it is p routine but maybe, we'll see how spammy I feel once it is posted.

Am 15.08.2022 um 17:08 schrieb Adam D Ruppe:
> In my blog this week, I described an idea I've had percolating in my brain for a bit about a user-defined effect system that could potentially move nogc, safe, pure, etc to library aliases - which would let you combine them as a fun bonus - among other things:
> 
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_15.html
> 
> Like with other inferred attributes, the argument-dependent and virtual function caveats had to be mentioned, but since I talked about them in other posts not too long ago I didn't want to go over it all again.

That would be really nice to have. I also had a similar idea in my mind for a while, with lots of potential use cases that came up in the past.

The most prominent example would be something like vibe.d's `@blocking`, which currently just acts as documentation, but would be really useful if something like `@nonblocking` could actually be enforced at compile time - currently there is just a runtime solution for that.

On Monday, 15 August 2022 at 16:16:35 UTC, Sönke Ludwig wrote:
> The most prominent example would be something like vibe.d's `@blocking`, which currently just acts as documentation, but would be really useful if something like `@nonblocking` could actually be enforced at compile time - currently there is just a runtime solution for that.

Aye, async in general has a lot of uses of this kind of thing. In addition to just not hogging the worker thread, being responsive to a cancellation request is a nice thing.

Speaking of blocking, one of the effects I'd envision is something like "loops". Something blocking on a loop can more harmful to the event-driven i/o model than other blocks - at least other blocking calls can be interrupted by signals or something.

On the one hand, you might think of it as madness to say `denies_effect!loops`. How will you get any work done? But there's two interesting bits: 1) you might be able to define it with higher order functions and 2) D's `foreach` loop is special.

See, a foreach loop can just by syntax sugar over an opApply function call.... and we could say one of those loops instead just has the effects of opApply (which would necessarily add the effects of the user-provided delegate, of course).

So you could imagine an opApply that uses the hidden effects escape to implement a loop, but inserts its own periodic `if(yield() == CANCEL) return;` logic, providing both regular returns to the scheduler event loop and opportunities to cancel the task. Indeed, the work chunks may even be auto-parallelized in the process too.

Of course, users could also use the trusted hidden effect, but the act of doing so at least reminds them that they ought to be careful.

On Monday, 15 August 2022 at 15:08:01 UTC, Adam D Ruppe wrote:
> In my blog this week, I described an idea I've had percolating in my brain for a bit about a user-defined effect system that could potentially move nogc, safe, pure, etc to library aliases - which would let you combine them as a fun bonus - among other things:
>

I know it isn't really related, but currently on DUB there is 4 different @nogc nothrow string library, -betterC or not, friendly licence or not, with various tradeoffs, and I'm about to add another one.

D is balkanized in concentric circles:
- -betterC D
- disabled runtime D
- @nogc D
- full D

And more basic building blocks are being made for the least restricted part of D, such as allocators and concurrency. At a more basic level, we cannot share code.

And I'm building another.

Allocators already working, tons of Unicode stuff implemented.

Working on string builders atm.

But one key difference is it is designed to work with the GC even if it is -betterC @nogc @safe nothrow.

On Tuesday, 16 August 2022 at 15:01:05 UTC, rikki cattermole wrote:
>
> But one key difference is it is designed to work with the GC even if it is -betterC @nogc @safe nothrow.

How do you do that?

On 17/08/2022 3:05 AM, Guillaume Piolat wrote:
> On Tuesday, 16 August 2022 at 15:01:05 UTC, rikki cattermole wrote:
>>
>> But one key difference is it is designed to work with the GC even if it is -betterC @nogc @safe nothrow.
> 
> How do you do that?

Via dub's injectSourceFiles (that I added).

https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/gc_hook.d

https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/gc.d

https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/locking.d#L111

On Tuesday, 16 August 2022 at 14:57:04 UTC, Guillaume Piolat wrote:
> I know it isn't really related, but currently on DUB there is 4 different @nogc nothrow string library, -betterC or not, friendly licence or not, with various tradeoffs, and I'm about to add another one.

Yeah. I think some of that is going to happen regardless just because a lot of us have the not-invented-here syndrome, and some of the tradeoffs are rooted in legitimate concerns.

When they have legitimate concerns, whether you have an effect annotation or not doesn't really matter (though the static checks are not always the best way to do it; a dynamic runtime check or a test suite might be just as good or even more appropriate). The lib might not be formally documented as unsuitable for you, but if it does something you can't allow, you're gonna be forced to find an alternative.

So I think multiple libraries for different requirements is always going to happen, and is actually a good thing. And having this documented and/or tested (again, whether static checks or runtime checks) can also be a good thing. Sometimes at least.

Though with D I think we're more duplicating because of just NIH or other sillier reasons than due to actual hard requirements in use. But still some of them are and even if we all worked together perfectly, we'd still want some separate libs that choose different trade offs.

On Monday, 15 August 2022 at 15:08:01 UTC, Adam D Ruppe wrote:
> [...]

It's one of those things where it is better for learning a language when there are a smaller number of orthogonal features that can be built up into more complex things. @safe, pure, etc. are good, but feel a bit hackish when coming new to the language.

Would require a DIP and some work in implementing it.