From 6246a38cbe3dec48cdc8361ce2f6d1d9a5a5d18c Mon Sep 17 00:00:00 2001 From: mlemanczyk Date: Sat, 7 Jan 2023 20:52:26 +0100 Subject: [PATCH] Tiny update --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fee95be..9a9705b 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ Having protection against invalid state of the object is an important part of so This decision is driven by performance measures. Considering wide use of the lists on the hot-paths, each additional check & operation starts counting. I've decided to eliminate all the checks for the sake of performance. If you feel that you need additional protection, feel free to inherit or reuse any of the provided classes to provide that. -## `this[int index]` & `Count` may overflow, but... +## `this[int index]`, `Count`, `IndexOf(T item)` etc. may overflow, but... All the classes included in this package support `long` indexing and addressing. The `LongCount` property will always provide the total no. of items stored on the list. Since `Count` is just `LongCount` typecasted to `int`, its value may overflow. But `List` addressing is kind of currently limited to `int` ranges anyway in practical scenarios. As such `Count` overflowing shouldn't be an issue when using the classes with existing code. If you use `Count` in your loops, it's recommended to replace it with `LongCount`, tough. You don't need to make any changes in `foreach` or other iterator loops. They are expected to transparently use the new classes & yield all items, beyond `int.MaxValue` range.