AlekXL

I tried to show my point And Rudy gave some reply Then I just asked Rudy to stop beating around the bush, and give us use case of those "problems" And now we waiting, what he could possibly reply?

Then Rudy added "possible problems and disadvantages"? Which are? I could easily point out obvious and incontestable advantages (need I really), but surely I would abstain from even dreaming it , in fear of some vague "bitter end"

Which I responded I explained in detail, how such objects can coexist. Learn to read. If you so sure, pray tell, {$J-} const strTypedConst:string='FOO'; var bar:string; begin bar:=strTypedConst end. Is strTypedConst constant is ref-counted? Effectively? And bar variable? What actually happens, when its value assigned to bar? Same goes to non-arc objects -- they just have their FRefCount locked , by some negative "magic" value, in constructor. Effectively, their are not ref-counted. Surely you know, that ctor invocation has hidden param, which tells whether to call NewInstance, or not (1 or 0 respectively). Why not add value 2, which would instruct the ctor, which memory model to use (1 -- for classic objects FRefCount locked, 2-- for auto objects.  And yes, before you ask stpd question -- assigning non ref-counted instance (variable) to a ref-counted variable should be forbidden at compile time -- I wrote this before

Then Rudy commented about coexistence of ARC and non-ARC objects

Then I posted my musings about Marco Article they would coexist just fine. Arc -> non arc unsafeInstance := unsafe(safeInstance);// you are on your own is valid, although not safe. Just add hidden 4-byte field to TObject, at negative offset, FRefcount. Like in string constants, make sure this field is negative for non-ARC instances. According to the type of variable (class OR auto class), which currently manipulate instance, compiler would know, whether to call gen _Addref and _Release on assignments. Generally, yes, if you are talking about generics. But RTL and FMX should not use ARCed instances anyway. And for user code, kindly let's us decide for ourselves. Again, non ARC instance pointer would be able to hold ARCed instance For whom, may I ask? For me this is Merlin's blessing! 

I strive to do so, every time. Are my comments imply I don't understand their position? Please supply an example or two All humans make mistakes. But some humans' mistakes would cost too much, if those deeds are not condemned Look, I tried my best to never give negative judgement on people, just their doing or words. However, if you think my effort is not enough, I'll try to be more subtle with my assessments

Please give an code example, not a vague words. What is the mysterious problem you taking : "this isn't working for interfaces"?! Can non-refcounted instance hold member instance of interface? Yes. They do that all the time. Can an ref-counted instance hold a reference to non-ref-counted object? Yes, absolutely. string stored in executable image, readonly, with magic FRefCount value (negative)

You don't realize, what a monster you could hire for 2-3 grand in Russia, do you? C++ expert with 15y+ experience, and parsing expert on top of that. He would run circles around both me and you. Need I repeat myself? And if the compiler source code is unmanageable even with such expert, well, it's beyond salvation then, and there is no reason to hide junk from community. Better start reworking it now, or Delphi is doomed. Absolutely! Bold moves made Delphi great. Bold and clever, not bold and stupid. You mean, except milking Delphi user-base to the end? We both know what they need. Real feedback system, accountability, responsibility ... Marco is clearly failing in that department. Simply out of the loop. The end is looming anyway. We are loosing young developers, to python, C#, etc. Even FPC/Lazarus somehow is getting some momentum sure, 1 gatekeeper for compiler is too expsensive, and several ones for RTL/VCL/FMX are quite affordable, aren't they? Your coherence is exemplary (of you-know-what) You don't get it, how EMBT makes money, do you? They charge users for bugfixes, especially in FMX, forcing to buy new versions or pay for subscription. Once people would able to fix current version of the libraries, by joint effort, or Merlin forbid, would have access to a newer release, sales will drown.

What are talking about? Uniquestring is about COW on top of ARC! Nothing to do with ARC itself. Where I suggested to make instances COW capable? Think! If ARC pointer to instance is to be passed as var parameter, it's just passed without anything. procedure Modify(var instance:auto TObject);// auto here is mandatory to accept ref_counted instances begin instance := auto TObject.Create();//instance is replaced, _Release is called, then ctor! // _Release with do NOTHING if FRefCount is NEGATIVE! end; procedure Test(); begin var inst := auto TObject.Create(); Modify(inst);//just pass without any fuss var classic = TObject.Create;// Non refcount, FREFCOUNT := -1000 Modify(classic);//just pass without any fuss end;

(Emphases are mine) Not-so-thinly-veiled sabotage of my motion! Too long, too expensive, too bad, too expensive again, too soon... After some time, I have no doubt you'll politely and wisely concede: too late

Guess I need to repeat myself FRefCount should be stored at negative offset (I think, like in strings) for all instances -- ref-counted or not. But if a variable is not "auto class" _Addref and _Release should not be generated, on copy or de-refence. Notable exception -- self special variable, with should call those in both cases. That way the each class implementation code would work for both cases, allowing auto class to be derived from non-refcounted one. Magical _Addref and _Release would have no effect, if FRefCnt is negative -- this is a fail-safe during runtime. FRefcount should initially set during constructor invocation, based on hidden param, either to negative, or to 0 (+1, before ctor starts), (1 -1= 0, after constructor is done)

typed string constants do have tstrrec structure, their values can be stored in string variables without copying its value, and magic functions to addref and release are called on them, with no effect. So they live in the world of arc without their lifetime being affected by this. That's how non refcounted instances should live what's refcount value of instance pointed by bar, after this assignment, in your opinion?

At least somebody thinks 1 step ahead here.

I explained in detail, how such objects can coexist. Learn to read. If you so sure, pray tell, {$J-} const strTypedConst:string='FOO'; var bar:string; begin bar:=strTypedConst end. Is strTypedConst constant is ref-counted? Effectively? And bar variable? What actually happens, when its value assigned to bar? Same goes to non-arc objects -- they just have their FRefCount locked , by some negative "magic" value, in constructor. Effectively, their are not ref-counted. Surely you know, that ctor invocation has hidden param, which tells whether to call NewInstance, or not (1 or 0 respectively). Why not add value 2, which would instruct the ctor, which memory model to use (1 -- for classic objects FRefCount locked, 2-- for auto objects. And yes, before you ask stpd question -- assigning non ref-counted instance (variable) to a ref-counted variable should be forbidden at compile time -- I wrote this before. So maintaining 1 expert "gatekeeper" is problem to EMBT? Some Russian or Chinese guy, who wouldn't ask more that 2-3 grand a month, working remotedly? If yes, then EMBT should close their RAD business, not wasting our time. And before you ask, the gatekeeper would have time to catch up, before pull request would become non-stop, and contributors would teach him basics for free. There is no right day like today, there is no right time like now. That should have been done years before. Window of opportunity might close very soon. System.pas is part of RTL, good luck compiling it with wrong compiler version! Have you ever dare to recompile it? As for FMX, old RAD versions users would love to have FMX bugs fixed for free, and damn the EULA.. Who would delve into which version of FMX is actually compiled into your app? Your advice would ruin the company. Well done.

Your way isn't working. We won't live that long, to encounter a sunny day, with such pace. Just listen to yourself! They did disable 1-byte strings on Android platform, which internally use Utf8 encoding. Extremely stupid move. Then they reformed. That happened long time ago, I don't even remember when, but you still hopeful. Now, let me try my way and get dirty for others' sake. Maybe I'm not the guy Delphi need, but surely the one it deserves. Vague. I am self-proclaimed Delphi evangelist, and those who fall to heresy, would not get my approval.

Marco was right, when he said that forced arc is no-go, because of legacy, and fragmentation. But why would he say, that on-demand arc is not viable? they would coexist just fine. Arc -> non arc unsafeInstance := unsafe(safeInstance);// you are on your own is valid, although not safe. Just add hidden 4-byte field to TObject, at negative offset, FRefcount. Like in string constants, make sure this field is negative for non-ARC instances. According to the type of variable (class OR auto class), which currently manipulate instance, compiler would know, whether to call gen _Addref and _Release on assignments. Generally, yes, if you are talking about generics. But RTL and FMX should not use ARCed instances anyway. And for user code, kindly let's us decide for ourselves. Again, non ARC instance pointer would be able to hold ARCed instance For whom, may I ask? For me this is Merlin's blessing! lame, lame excuse. Let us disable ref-counting on strings too, surely rookie still can't grasp that strings, dyn-arrays, and interfaces should always be cast with const. And why use cautiously , you should use them boldly. What is the scenario when const can backfire, pray I tell? Surely, if compiler could detect unused variables, it also can omit addref/release + exception frame generation, when said argument is not assigned? --- Had your company 1 half-bad compiler engineer, even completely unfamiliar with the source code, on-demand ARC would be implemented in 1 month. Surprisingly, you don't need to understand source code completely to be able to successfully modify it. Find places in syntaxer ( can't believe top-down parser may be that complex), add auto class notation, auto constructor invocation. Make auto class type distinctive from normal, in the symtable. Make sure that VMT gen would process auto and normal class twice. Find places of interest : class instantiation, assignments, by-ref arg passing. Make sure those assignments either ARC to ARC, Normal to Normal , or unsafe(ARC) to Normal. Do your patch. Cover with test (something your guys don't usually do) Fix issues. -- Job done.

old news. Best news is inline variables and deprecating ARC. Neither. "For they have sown the wind, and they shall reap the whirlwind", Hosea 8:7. You were quite critical about my demeanour, well, you always reap more than you've sown. Nature's law, God's Word, uncontestable anyway.

sad but true

Whatever it takes to set the record straight I use qpython3 and fanficfare package on the command line to fetch fanfics from not-so-popular websites. This is only option on Android. I already said, that Borland should have pursued JVM target platform instead of wannabe-portable .NET. I just don't believe in loosely typed languages, and don't particularly like those languages which take your freedom to shoot in your leg. This is obvious, that Delphi is not so popular.The question what to do? Nearly all the power of no-so-strict languages comes from binding from C++, right? And we already settled, that's not easy task to do the binding. So there must be C++ developers, who's backing this.. So why those true developers spend their time binding to scripting languages? Probably because they need simple front-end for those libraries, and community wisdom (lab rats). After all C++ is anything but simple. So those devs invent and reinvent the wheel, creating new scripting dialects to met their goals. This never ends, because those wheels might shine in something, but are weak in the rest. And delphi is such language -- simple, but not stupid. Free to do dark magic (certainly, for greater good), but providing some fail-safe features. We just need some more sugar -- on-demand ARC, more concise lambda syntax, like LAMBDA = ARGLIST => LAMBDA_BLOCK LAMBDA = ARGBLOCK_SINGLE => LAMBDA_BLOCK ARGLIST = ( ARGBLOCK ) ARGBLOCK = ARG_NAME_LIST [: ARG_TYPE] ARG_NAME_LIST = ARG_NAME, ARG_NAME_LIST ARGBLOCK_SINGLE = ARG_NAME [:ARG_TYPE] LAMBDA_BLOCK = begin R_BLOCK end //do inference for function result type, from assignment LAMBDA_BLOCK = SINGLE_COMMAND var myLambda = a:integer => Result:=a+1; //PASCAL==less parens, Luke var sameLamda= function (a:integer):integer begin Result:=a+1; end; auto properties, like property property Prop:integer read, protected write; //maybe even with initialization and inference property Dic:var read, protected write = TDictionary<string, TObject>.Create(1,TIStringComparer.Ordinal);// FDic will be automatically FreeAndNil -ed in dtor inline field initializers(including ctors with auto finalization) private FDic:var=TDictionary<string, TObject>.Create(1,TIStringComparer.Ordinal);// FDic will be automatically FreeAndNil -ed in dtor record (or, better, old TP objects') auto constructors (those C++ guys are RAII heretics, after all) maybe even dot operator overloading for value-structures. And Object Pascal might be the language to find those, bring them to ready ecosystem, and make them bind their libraries to the language. And we still have some rats, too. Only we need to forge a ring (not-a-wheel) of tools: updated freeware compiler, LLDB binding(I-PASCAL have some), language server, and gui designer

Being so pricey (Delphi), and so ugly (Lazarus), no wonder.. And perhaps we should not just count repos, but make sampling inspection, to draw some conclusions Look, I've just have different mindset to tackle this. If I were about to build a video player, it should have something really, deeply unique features. Say, to my knowledge, Android is lacking any Video Player, which support software brightness and hardware acceleration. A few support brightness when decoding on cpu. I can't believe it's impossible on principle, but apparently this is not low-hanging fruit, otherwise some players would have it. So I need to dig very low level to achieve my goal, C/C++ level, maybe deeper. And for testing purposes I can use quick-and-dirty python wrapper, sure? Would it make me a python developer? No. Because if I succeed, I will go to great lengths to hide my solution, otherwise some copycats would just steal my ideas. So I'd go really hard-to-crack solution -- either C++, or Pascal, because it's not easy to de-compile those. And damn the difficulties. This approach is completely different from yours, so I could monetize this. If a worthy work is opensource this means one of 2 cases: 1. Author (copyright holder) are big company. They have their reasons to do so. 2. One is an individual, and he don't earn on opensource, but rather, earn working on a "big brother", which owns most of his time, and most of the code he's written Surely, I'm not #1, and don't really want to be #2. But I agree, Pascal ecosystem is nonexistent on Linux. And since I don't want to defect to cool python community, I need consider other options, which include fpc upgrade, debugger binding, language server, and gui designer. And for free, at least for those who work for $0 gain.

It's Alec, actually. It helps me stay at least loosely on-topic, and serve a friendly reminder (can't believe I wrote this) for others to the same end. I'm aware, but one could plant some seeds in others' minds. Even provocative approach serves the cause. Isn't this enjoyable, guilty pleasure, to follow this controversy? At least for out-of-the-box thinkers? And we discover something, like Swig, worked out feature like on-demand reference counting. We are productive here.

Apparently, this is easier to buy a good product, rather then craft your own one -- the manager needs to be competent on-topic, and be able to deal with coders. More competent among those are not social climbers, occasionally, but rather deplorable anti-social folks. But I think JVM target is more practical and feasible. That should be the first platform aimed after win32.

@Joseph MItzen Could you please provide link for that issue with regex and Baurer case? QC/QP and forum topic.

Well, what can I say? outright stupidity, outrageous neglect Again, same.. And this is bring us the back on-topic, we on page #6, and we need to reach those making decisions, and the first step is to open-source Delphi compiler, please vote on QP , if you didn't already

Its most recent v4 fork (https://github.com/FMXExpress/swig), dont know whether usable, but I used http://www.fmxexpress.com/wp-content/uploads/swig-delphi.7z which is build of v3. https://github.com/FMXExpress/swig-delphi