Stefan Glienke

https://bitbucket.org/sglienke/spring4d/src/2.0.1/Source/Base/Collections/Spring.Collections.pas#lines-6391

First of all, you can already achieve what you asked for in two different ways. (As I said, I will look into adding a similar method as .NET 9 did, but it's not as easy due to Delphi's limitations - it most likely will be a static method on TEnumerable and not on IEnumerable because it returns a differently typed IEnumerable, and that causes the Delphi compiler to complain with E2604.) Apart from the obvious use of a classic for-to loop if you already have an indexable collection such as IList where that new method IMHO would make no sense and just add overhead you can do this: var indexedColl := TEnumerable.Zip<Integer,TMyClass>(TEnumerable.Range(0, myColl.Count), myColl); for var curItem in indexedColl do Writeln('index: ', curItem.Value1, ' - item: ', curItem.Value2.ToString); If you want more control over index generation you can write this: var indexedColl := TEnumerable.Select<TMyClass, Tuple<Integer,TMyClass>>(myColl, function(const item: TMyClass; const index: Integer): Tuple<Integer,TMyClass> begin Result := Tuple<integer,TMyClass>.Create(index, item); end); for var curItem in indexedColl do Writeln('index: ', curItem.Value1, ' - item: ', curItem.Value2.ToString); If you then want to filter only certain indexes you just call Where on indexedColl: var oddIndexes := indexedColl.Where( function(const tuple: Tuple<Integer,TMyClass>): Boolean begin Result := Odd(tuple.Value1); end); for var curItem in oddIndexes do Writeln('index: ', curItem.Value1, ' - item: ', curItem.Value2.ToString);

This would be a duplication of the already existing Where

I have something like that in the works already. It does create a copy (records are value types, what else should it do?) - what you are proposing is dangerous and error-prone. That is not the case anymore in 2.0 - that interface has been removed from lists.

No, but I see that .NET 9 added this. I might consider it.

FWIW if your type is an enum already it makes no sense to use ISet<T> because you can use the enum set. ISet<T> is for types that are no enums, such as string for example.

Passing parameters like that does not work in DUnitX - it silently ignores the string name for the exception class and then passes nil. Calling Assert.WillRaise with nil as exceptionClass succeeds when any exception was raised. @Vincent Parrett should be able to tell the best way to pass any parameters that cannot be easily converted from string.

Converting source code that won any challenge over 15 years ago is questionable regardless of correctness. Anyway, for this particular example, implementing a faster System.Move for Windows (other platforms use their libc memory) has been solved since Delphi 11.3. I sincerely challenge everyone to come up with a faster/better implementation.

It is pretty simple - imagine if the code below would work that way: procedure ReplacePet(var pet: TPet); begin pet.Free; pet := TCat.Create; end; procedure Main; var dog: TDog; begin ReplacePet(dog); dog.Bark; // meow?! end; FreeAndNil is special because it just destroys and assigns nil. But a var parameter does not give that guarantee.

Which - fun fact - does not happen on the method call (unless it's a virtual method) but when accessing any member inside of it. You could still have some method which does not access any member and it will not AV at all. We can argue all day about this - any runtime behavior one might slap onto it will not save the language from being inherently unsafe. It needs to be built into the language/compiler itself (Hi, Rust)

The main issue with memory safety in Delphi is not non-initialized local variables, which the compiler warns about, but use-after-free.

First, it's wrong to assume that all local variables reside on the stack, depending on optimization they might be in registers. Second, rep stosd is terribly slow for small sizes (see https://stackoverflow.com/a/33485055/587106 and also the discussions on this issue https://github.com/dotnet/runtime/issues/10744) Also, the Delphi compiler arranges managed local variables into one block that it zeroes (in many different and mostly terribly inefficient ways).

Why should the CPU waste time zeroing stuff that will be set shortly after anyway? Compilers are there to warn/error when any code path leads to a situation where a variable is not initialized.

type TCustomItem = class; TCustomContainer = class abstract protected procedure HandleItemNotification(AItem: TCustomItem); virtual; abstract; end; TCustomItem = class protected FContainer: TCustomContainer; end; TCustomContainer<T: TCustomItem> = class abstract(TCustomContainer) protected FItems: TArray<T>; procedure HandleItemNotification(AItem: TCustomItem); overload; override; final; procedure HandleItemNotification(AItem: T); reintroduce; overload; end; TFooItem = class(TCustomItem) procedure SomeMethod; end; TFooContainer = class(TCustomContainer<TFooItem>); procedure TCustomContainer<T>.HandleItemNotification(AItem: T); begin // ... end; procedure TCustomContainer<T>.HandleItemNotification(AItem: TCustomItem); begin HandleItemNotification(T(AItem)); end; procedure TFooItem.SomeMethod; begin FContainer.HandleItemNotification(Self); end; var foo: TFooItem; begin foo := TFooItem.Create; foo.FContainer := TFooContainer.Create; foo.SomeMethod; end. I suggest moving as much code into the non generic base classes as possible. Given the constraint on TCustomItem this should even be reasonably easy to achieve. This will prevent causing larger than necessary binary sizes and longer than necessary compiletimes.

Yes, pretty much - we all know they first ship a half-baked feature to generate marketing hype and then spend the next decade tinkering around the edges to make it work while representatives are telling us "eh, its complicated"