That sounds cool, but this quickly gets complicated. Some aspects that need to be addressed:

- where does the automatically defined struct live? Data segment might work for static, but doesn't allow dynamic use. Stack will be garbage if closure outlives function context (ie. callback, future). Heap might work, but how do you prevent leaks without C++/Rust RAII?

- while a function pointer may be copied or moved, the state area probably cannot. It may contain pointers to stack object or point into itself (think Rust's pinning)

- you already mention recursion, compilation

- ...

IMO the C way is to allow users to explicitly manage context area, along the lines of posix ucontext.h or how the author's closure proposal handle closure allocation[1]. [1] https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functio...

Yes that's what I'm thinking. Essentially a stateful function definition defines both a function, and a struct containing the state. I think there needs to be two ways of invoking a stateful function f: (1) if you invoke f within another stateful function g, each call site in g that calls f automatically gets a distinct state instance that becomes part of g's state, on the other hand, (2) if you want to invoke f in a regular (non-stateful) function, you need to manually manage the state and explicitly pass it in. That would be one purpose of the statetype(f) operator: to allow you to explicitly declare a state instance. Manual state management would also be used when you want to invoke f with the same state multiple times (e.g. from within a loop).

In C I don't think the copy/move thing is an issue. It has the same hazards as copying struct instances. And yes I am thinking of this as a C extension.

Another complication is that it would be beneficial to be able to optimize state storage in the same way that stack frame resources are optimized, including things like coalescing equal values in conceptually distinct state instances. This would (I think) preclude things like sizeof(statetype(f)) which you really want for certain types of manual memory management, or it would require multiple compiler passes.

Interesting. I guess that analogously, we might find that X years after some future AI content production ban, we could similarly start ignoring the low background token issue?

We used a rather low number of atmospheric bombs, while we are carpet bombing the internet every day with AI marketing copy.

The eternal September has finally ended. We've now entered the AI winter. It promises to be long, dark, and full of annoyances.

"Winter" in AI (or cryptocurrency, or any at all) ecosystems denote a period of low activity, and a focus on fundamentals instead of driven by hype.

What we're seeing now is something more like the peak of summer. If it ends up being a bubble, and it burtst, some months after that will be "AI Winter" as investors won't want to continue chucking money at problems anymore, and it'll go back to "in the background research" again, as it was before.

It was a continuation of the nuclear analogy, a nuclear winter following a large scale nuclear exchange.

Also that winter comes after September (fall)

We instead entered eternal December.

We're bombing the internet into extinction. But we were way before AI. It got real bad during the SEO/monetization phase. AI was just the final nail.

We used a low number _and_ it was a while ago (it would be different if we used the same number spread out on the same time span)

What’s the half-life of a viral meme?

... And what if a competing mobile OS (say iOS or android) received payments or donations from said organization :-)

I think the point is not about us being developers or employees, but about us being a civilian.

But would you be willing to pay for it? Would your company/organization be willing to move?

Absolutely not

Indeed. If DRM had the technical merits to protect against copying, why would we need a (law like DMCA) against tinkering with that technology?