fpc unleashed <> fpc?

[landrix]

To what extent is the fork an irreversible split from FPC? Is there any chance of a merge back into FPC?

[fibodevy]

Technically it's not a split at all - it's a downstream fork, regularly synced with upstream. It's 100% compatible with FPC: it's FPC with features on top. The only catch is that if you use those features, they simply don't exist in stock FPC.

Bugfixes already flow back: when I hit an FPC bug, I send the patch upstream, and a few have been merged.

The language features are the other side of it. They're in the fork precisely because upstream said no, so merging them back is upstream's call, not mine. The code is open, and if they ever want any of those features, they're free to merge them. I'm not counting on it, though - that's the reason the fork exists in the first place.

[landrix]

That’s what I suspected regarding why the features aren't making it into the upstream. It’s a real shame. Still, it’s good that you’re trying to keep that option open. Maybe the time will come eventually :)

Is this a hobby project for you, or are there bigger plans behind it?

[fibodevy]

No real plans - whatever happens, happens. If it picks up a bit more traction, I'm hoping someone joins in and helps maintain it.

Not purely a hobby either: I use these features in commercial projects. So realistically - as long as I keep coding in FPC, I'll keep Unleashed maintained and add new things now and then.

[landrix]

Your answer from July stuck with me: technically the door is open, but the language features are in Unleashed because upstream rejected them.

So let me ask it a bit differently:

If FPC had a clearer path for experimental language features — for example through modeswitches, an RFC process, or some defined route from experimental to accepted — would that make upstreaming selected Unleashed features realistic again?

What would actually have to change on the FPC side for you to consider that worth the effort?

I think it would be a shame if both projects gradually drifted too far apart.

[fibodevy]

Let me answer with a quote from the forum:

This is volunteer work, done in my own time and at my own expense, and all of the code is public. Take it and put it in stock FPC - that is what a permissive licence is for. I will even help: if I am given a commitment that the MR will actually be merged, I will prepare a stock-FPC version of an Unleashed feature myself. Pick one. The only exception is Int128 - it is too large to port on a promise, with nearly 5000 lines spread across 68 files in the compiler and RTL, not counting tests and docs. Sorry.

What I will not do is spend weeks preparing a feature MR without reasonable confidence that it will be reviewed and merged, knowing what happened to !498.

So to answer your question directly: it's not about modeswitches or an RFC process. The real blocker is commitment - a reasonable guarantee that the work actually gets reviewed and merged. There are MRs sitting on the official GitLab for years. Anything that isn't a small fix just sits there.

[landrix]

Thanks, that’s how I assessed the situation as well. I mainly wanted to clarify where things currently stand.

I don’t have any particular influence, but I am very interested in contributing where I can and in helping Free Pascal move forward.