AlekXL

dismissal again? As you wish.

No. If container is not designed to manage lifetime, then it can be specialized once. And generics can be specialized as many times, as needed Again this is no more tricky than AnsiString, UnicodeString and RawByteString codepage-wise we would need containers for both flavors of objects and would make it impossible to mix them Not exactly. Example TMyListRaw and TMyListClassic can hold both flavors. type TMyListRaw= TList<raw TObject>;//can hold both flavors, ref_cout overhead, runtime checks, when extracting item type TMyListClassic= TList<TObject>;//can hold non-arc, and unsafe arc (static typecast),not ref_cout overhead (no lifetime management), //no runtime checks, can only extract non-ref counted items, type TMyListAuto=TList<TObject>; //can hold only arc-ed instances, no runtime checks, effective ref_count logic/lifetime management No. TMyListClassic can hold arced instances without runtime checks. It just don't manage their lifetime, neither it returns manageable instaces. No. There is no runtime cost for non-arced objects. Neither for legacy code, nor for "i-hate-arc" code. Cost added when you choose it. We already mixing memory management paradigms, when using objects through interfaces Playing dismissal game again? It's not about what will be done. It's about how it shall be done. Truth is truth. Perhaps some day EMBT Delphi would be forces to copycat FPC, not the other way around

yes, it can. Aside from unsafe typecast , it perfectly capable. Or did I forget some of your argument? Repeat it please, or provide a direct link to it. Yes, they can. No more tricky than AnsiString, UnicodeString and RawByteString codepage-wise no. There is methods that would not do refcounting, if they are designed to work with non-refcounted objects, or simply is not designed to manage instance lifetime yes, but only in case of raw class. Just like you do codepage checks on RawByteString

Semantics. You can coexist with your neighbors, without mingling with them. Problem arouses when they misbehave. If I follow your logic, then AnsiString cannot easily coexist with UnicodeString, let alone RawByteString classic is meant to be freed explicitly via FreeAndNil or similar. Modify is not responsible for managing lifetime of such variables Actually I find defect in my theory: You cannot pass non-arced variable as arced argument. This is because the container could return such non-arced instance into arced variable, which is invalid. We need some raw class type , which would accept both arced and non-arced instances (like rawbytestring which unlike AnsiString is codepage agnostic) . Caveat : raw typed instances cannot be passed as var or out params. Or with must require them to match exactly, as usual to such params. And unlike RawByteString they cannot not be assigned to either flavor of instance without explicit typecast like TRawObject = raw TObject;//can point to TObject as well as auto TObject function DoSomething(const instance:raw TObject):string;// raw here is to accept both flavors! Arced or not! begin result := instance.ClassName; end; procedure Test(); begin var inst := auto TObject.Create(); var str=Modify(inst);//just pass without any fuss var classic = TObject.Create;// Non refcount, FREFCOUNT := -1000 str := Modify(classic);//just pass without any fuss end; And yes, with need a runtime type check to detect, whether we a dealing with unsafe or not, and also safe typecast as procedure Check(const inst: raw TObject); var obj:TObject; type TAutoObj= auto TObject; var autoObj:TAutoObj; begin if inst is unsafe then // unsafe is going to be keyword anyway, as operator casting obj := unsafe inst //OR //obj := TObject(instance);//same! else autoObj := inst as TAutoObj;//or maybe // autoObj := inst as auto TObject;// but since auto is directive, // this can be tricky to stupid LL(top-down) parser do detect, where auto is directive, and where is symbol name end;

VCL is not designed to such approach. What if your listbox contains 1 Million items? Each t would contain 2 buttons? You need to owner-draw listbox items to achieve that, and add mouse interaction with active item -- yes, manually. Or use some third-party rendering. Say, free htmlviewer can do that, I guess. Html components (paid) would do that, too

Let's vote for my request

They are both Delphi incompatible, I believe. Fakes. Lure a decent Delphi coder into a schism. Provoke writing code any other Delphi developer can't use. Taking away solidarity and unity of Pascal Community. Fragmenting already small community. Causing efforts to promote Pascal even harder. Burn the heretics! LGPL is half-bad when you use code in dynamic library, without any considerable modification. But what happens, when you borrow code to your proprietary application? Violation! Or extend the LGPL code? MSELang is not a library I presume, so it is unclear what happens. You can be sued -- that's for sure, whether you win or loose in the court of justice -- you'd loose at least time, and money for lawyers. You can borrow LLVM code, as well as BSD, MIT, Apache licensed sources. Just give the devil his due -- some credits, and you're safe. And GPL/LGPL is infection. Any linking with it is a legal threat.

No. Containers are shared. TList generic could easy hold both ARCed and non-ARCed instances. Yes, such container would specialized differently by compiler, but who cares? As well as TDictionary, TQueue, or TStack, etc. But yes, normally one should not mix them. However if you are expert, and know exactly what are you doing, then yes, go ahead and mix them. Couple of unsafe operators -- thats easy. Just don't complain, if you miscalculated and such mixture backfires.

And why should you care? Don't like it? Don't read it! With all my due respect. I worked out the whole on-demand ARC syntax, semantics, and philosophy upon @Joseph MItzen (valid) complain about Delphi current memory management state. And invalid lame excuse of Marco Cantu to lazy about doing ARC right I did it from scratch. And I opine this is best way to do ARC on Delphi right. ARC is of utmost importance, too. Non just your lambda or automatic properties syntax sugar.

Correct. You shouldn't usually mix them. Some instance types would live on ARC, some would live like "normal". To mix them, You need to understand what exactly are you doing. The whole (and any) ARC memory model is conceptually more sophisticated that simple manual memory management. No need to pretend it is simple, I opine. My way is backward compatible, gives opportunities to those who dare use them and wouldn't force anyone any particular code style. But if yes, they are rare, overhead is low, who cares?

but a lot of directives, right? automated, varargs, protected, strict protected, reintroduce, dynamic, dispid and more and more ... Delphi power is about readability -- less braces, brackets, and parens, comparing to C/C++. They are pain to read, pain to write Attributes especially compiler-like like [ref] [unsafe] [weak] [volatile] -- this is real blasphemy Generics syntax are just barely better. It's wouldn't hurt anyone to add a keyword or two.

clarify full signature of Share function. (signature stands for full declaration)

Wait a second. I can only pass non-ARCed objects to that container?  Again, you are rushing, the container you quoted is designed for ARC. Could you pass non-ARCed instance there. I guess yes. It would be some overhead on _AddRef and _Release, but the code would work as expected anyway Alternatively, you could pass ARC-ed instance to a non ARC-ed container, provided(if you're sure), you use operator unsafe ( initially I thought about unsafe function , but it's not pascal way to abuse parens, so unsafe is low-priority right-associative operator) procedure MyContainer.Add(A:TObject); //can only hold non-ARCed or unsafe instances begin var auto1 := auto TObject.Create(); MyContainer.Add( unsafe auto1);//you used unsafe, now you are on your own. Risk it, if you are sure end; Of course, adding Arc-ed instance to a TObjectList , which ownObjects=true is outright stupid. But TList<auto TObject> standard generic is quite alright. Again, from the compiler standpoint auto class type is not fully compatible with non-auto same_class type TAutoObject=auto TObject; TAutoObject would share VMT with TObject, maybe even RTTI (not sure), but still it's different type

Because SharedPtr would be generic. You can't avoid that. So yes, brackets , braces, <whatever>. Type inference sucks when it comes to generics. // Auto is "mrecord" implementing shared_ptr pattern var shared := Auto<TObject>.Wrap (TObject.Create);//uglies, stupid type inference, like present, I think var shared2 := Auto.Wrap(TObject.Create);// smarter, type infered, but still ugly -- abusing parens, like C++ var shared3= auto TObject.Create;// on-demand ARC, by AlekXL. compiler magic! yes. I'm saying just that.

No! Add knows, A param is not ARCed. Otherwize it would be procedure MyContainer.Add(A:auto TObject);

And now who is being rude, Rudy? Not even smartly so.. I was talking about SharedPtr pattern implementation with your fancy mrecords. ------- No. Only for those variables which of auto class. Simple non-ARC-capable variable thus wouldn't generate any overhead. I need to repeat that, do I? type TSomeClassDesignedToBeAlwaysAuto=class auto(TObject)// this class, and all his descendants are ref-Counted. end; var simple:TObject;// no overhead, incapable of holding arc-object, due to compile time error, except unsafe typecast var autoExplicit: auto TObject;// incapable of holding non-arc-object, due to compile-time error var auto :TSomeClassDesignedToBeAlwaysAuto;//same traits as autoExplicit And It would, on compile-time. Why? Only on assignment and by-ref parameter passing.. Don't like it? Don't use it. Go classical manual memory management. You would have choice then, unlike in present ARC

It's terribly offtopic here, and even it's not mine off-topic to boot! Those records with default and copy ctors are nice. No one argues that. Although I'd rather see old TP objects to return in all their glory. Because, records are - just records.. Code without inheritance and polymorphism either is to achieve very simple tasks, or to create ugly, bloated, and hard-to-maintain solution. Yes, records with managed fields would be faster - which means they wouldn't terribly slow. So? If you are for speed, well, C++ is still way faster. Because it's GPL infected. Otherwise we would see many forks of it. Paid ones, too. GPL is hostile to developer. I already wrote here my maxim: Not so great. 32-bit Windows debugger is OK mostly. 64-bit is worse. GDB on android is outright horrible mess. And It was Borland, mostly, who created Delphi. Not Embarcadero. How many years it'll take? 30 years maybe, like from Turbo Pascal -> Delphi Rio? Lazarus is adopting LLDB now (not usable for now), there is hope. And honestly, being still ugly, FPC/Lazarus is actually already usage. I would say FPC is reaching critical mass. Actually, I'm considering opening new topic here, dedicated Delphi-compatible FPC development.

For who? It's 3 months of work of top C++ developer. In Russia. Seasoned, clever. Cream of the crop. Or half-year of Delphi one. No, if the source code is not bloated mess. You just need cover your work against the tests, run modifier version against existing ones, and do a public beta-test.. My point is shared_ptr pattern implemented with "mrecords" would be visually ugly, limited (no inheritance), inefficient both in speed and size, -- and also debugger-unfriendly. I would ask myself -- why would I use Delphi, if C++ does it just do same much better? I know some developer who'd do it. For several grand, anyway. And now dismissal. This is typical for you, isn't it? Advantage is automatic memory management of designated instances, and keeping classic manual-control model for others, and compatibly with legacy code(which is a much, even Marco now realized that). Every Unicode string carry as much of dead weight (codepage), and still you don't complain that? Someone is terribly wrong here, and I don't think it's me. At least I pointed out advantages, I would ask Dalia, which is also ARC fan, but I doubt she would respond without prejudice.

But Delphi is dying. Job market is close to non-existent. Freelance jobs too, unlike C# or C++. What's the point of your denial? And, your answer on mixing ARC and non-ARC is awaited https://en.delphipraxis.net/topic/988-on-demand-arc-feature-discussed/

Because their no point to do bad work for free. You either put your utmost, or just don't do. At least this is true for someone like me. And if those fixes is to be refunded by EMBT, you would wonder how cheap it will cost, especially from "3rd world" people. --- and if I were cynical, I'd say "open-source volunteers would do a better job because" anyone would do a better job. But I'm not, so I'd refrain from that standpoint

Are you a company CEO ? Some companies invested in Delphi so much, that could easy spend, say, 10 grand for fixing annoying issue. And probably you don't realize how low those fees on emerging markets Look what are you saying! Shared_ptr is OK, and on-demand ARC is "not easy" -- For your information my on-demand ARC proposition is actually the shared pointers , but backed by compiler magic! Why bother then, you would ask? Because Delphi compiler is not C++, is not insanely clever, sophisticated and stable compiler to implement those pointers in effective manner. It would screw up, undoubtedly! And on top of that we will get ugly c-like syntax, with braces, brackets, or how you call that. Get var shared := Auto<TObject>.Wrap (TObject.Create); instead of shared:= auto TObject.Create; I'd prefer first class solution over ugly workaround for Delphi language deficiency.

Here are 2 cases, why Delphi might be in not-so-good condition, to put it politely 1. EMBT is for "cost optimization" to the extreme.. Compiler engineers' team is lacking manpower, or they are mostly too cheap. Their resources stretched thin. This means Delphi is doomed (unless compiler is GPLed), and nothing can be done about it, until it's too late. Opensourcing the compiler then would just create some fail-safe.. 2. Compiler engineers' team is too expensive. Ask too much and do too little. In that case opensourcing the compiler could bring new, knowledgeable team of really devoted developers, who would compete each over, and would ask less money. No, they wouldn't be many. But even 5-10 of those around the globe would make all the difference. Marco wouldn't want accept fixes for free? Fine! Pay for a fix! Give some $50-$100 to poor student (some of them are incredibly bright), and own his work.

Because 1. they support too many platforms 2. do not pursue delphi compatibility strong enough 3. are lacking in debugger and ide department, which prevents synergy and positive feedback still right now FPC is getting critical mass… i believe

i guess i misunderstood. Still Marco practically said that effort on the compiler is the same as before. Nothing is to be changed, in his opinion. Surely, "delusional" was about myself

Well, see what Marco replied in QP Delphi compiler is of high quality right now .. Maybe it's me, who is delusional?