擴展索引器

處理 params

如果你有一個擴展索引器，例如 paramsint this[int i, params string[] s] { get; set; }，你可以有三種使用方式：

• 延伸索引： receiver[i: 0, "Alice", "Bob"]
• Getter 實作調用： E.get_Item(receiver, i: 0, "Alice", "Bob")
• 設定器實施調用： E.set_Item(...)

那麼，二傳手實施方法的特徵是什麼？
只有在使用者可調用方法簽名的最後一個參數有 params時才有意義，因此在 E.set_Item(... extension parameter ..., this i, params string[] s, int value)中沒有意義。

以下是一些選項：

1. 禁止 params 帶有設定器的擴充索引器
2. 在設定器實作方法中省略該 [ParamArray] 屬性
3. 不要做什麼特別的事（發出 [ParamArray]）

我會建議選項二，因為它能 params 最大化實用性。 代價只是擴充索引與消歧義語法之間的小差異。

決定（LDM 2026-02-02）：發射並 [ParamArray] 驗證對工具無負面影響

賦值對型別推論的影響

int i = 0;
i[42, null] = new object(); // fails inference
E.set_Item(i, 42, null, new object()); // infer `E.set_Item<object>`

public static class E
{
    extension<T>(int i)
    {
        public T this[int j, T t] { set { } }
    }
}

#nullable enable

int i = 0;
i[new object()] = null; // infer `E.extension<object!>` and warn on conversion of null literal to `object!`
E.set_Item(i, new object(), null); // infer `E.set_Item<object?>`

public static class E
{
    extension<T>(int i)
    {
        public T this[T t] { set { } }
    }
}

決策（LDM 2026-02-02）：索引器僅根據接收者及參數列表中的參數推斷（即指派值不具貢獻）。

擴展 Length/Count 性質是否應該讓型別可數？

提醒一下，綁定 隱含的索引器或範圍索引器時，擴充功能不會被用到：

C c = new C();
_ = c[..]; // Cannot apply indexing with [] to an expression of type 'C'

class C
{
    public int Length => 0;
}

static class E
{
    public static C Slice(this C c, int i, int j) => null!;
}

因此，我們目前的立場是，擴充屬性不應該被視為清單模式、集合表達式和隱含索引器的「可數屬性」。

如果我們在元素存取情境中暴露 this[Index] 或 this[Range] 擴充索引器，自然會預期目標型別能在清單模式中運作。
然而，列表模式需要 a Length 或 Count 性質。

延伸性質是否應該符合這個要求？ （這看起來很自然）

C c = new C();
var x1 = c[^1];
var x2 = c[1..];

if (c is [.., var y1]) { }
if (c is [_, .. var y2]) { }

class C { }

static class E
{
  extension(C c)
  {
    object this[System.Index] => ...;
    C this[System.Range] => ...;
    int Length => ...;
  }
}

但那麼，這些屬性是否也應該對隱含索引器備援（LengthSlice + Count/）有所貢獻，而該備援（）則用於缺少明確Index/Range索引器時使用？

C c = new C();
if (c is [var y1, .. var y2]) { }

class C
{
  C Slice(int i, int j) => ...;
}

static class E
{
  extension(C c)
  {
    object this[System.Index] => ...;
    int Length => ...;
  }
}

決定（LDM 2026-02-02）：擴充功能應在所有地方都有貢獻，包括可數屬性和隱含索引器備援。

確認擴充索引器的存取權是在隱式索引器之前還是之後

C c = new C();
_ = c[^1];

class C
{
  public int Length => ...;
  public int this[int i] => ...;
}

static class E
{
  extension(C c)
  {
    public int this[System.Index i] => ...;
  }
}

我已經將擴充索引器的存取設定為優先於隱式索引器的存取，但現在認為它們應該放在之後，以避免不必要的相容中斷。

更新（LDM 2026-02-02）：這需要進一步調查。 是的，延長應該在非擴展成員之後，但除此之外，我們需要根據上述決定提出具體提案，允許延長對隱含索引器備用機制的貢獻。

判決（LDM 2026-03-09）：順序為實例索引器、隱式實例索引器、實擴展索引器，最後是隱式擴展索引器。 請參閱 https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-03-09.md#extension-indexers

數量/長度：名字是優先考，還是非延長還是延長？

我們也有現有的備案： Length 優先於 Count 財產。 延長 Length 應該在非延伸 Count 物業之前還是之後？

決策（LDM 2026-03-09）：我們將逐項範圍檢視（從實例範圍開始，逐步到擴展範圍），在每個範圍內我們會先尋找， Length 然後 Count再尋找。 請參閱 https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-03-09.md#extension-indexers

確認隱含索引器的設計建議

我們逐個範圍檢視，從實例範圍開始，然後再到擴展範圍。
在一個範圍內：

1. 我們尋找真正的索引者，
2. 否則，如果我們有一個正確類型的單一參數，則尋找隱含索引器。

決定（LDM 2026-03-09）：不，一旦我們進入擴展範圍，我們將使用全程延伸解析度。

確認擬議的列表模式設計

對於帶有牌差的列表型態，我們將尋找：

1. a Length/Count
2. 真實或隱含 this[Index]
3. 真實或隱含 this[Range]

我們會分別尋找。 但當我們尋找隱含 this[Index] 或 this[Range]時，這兩個部分必須來自相同的範圍：

1. Length/Count
2. this[int]/Slice(int, int)

注意：當型別可用於列表模式（即可數且可索引）時，模式的非負處理 Length 才會生效。

決定（LDM 2026-03-09）：不，我們會依照這個查詢順序進行：

1. 列表模式的解析方式就像我們分別尋找長度/數量、索引器和範圍索引器
2. 對於指數與範圍索引器，流程如下：a。 僅用實例查找時，盡可能找出「真實」索引 b. 僅使用實例查找時，盡可能找出隱含索引器的各部分 c。 在完整查找（instance+extension）時，盡可能找出「實數」索引 d。 在完整查找（instance+extension）時，盡可能找出隱含索引器的各個部分（每個部分在個別查找中）

延伸 Slice 方法也應該有影響嗎？

_ = c[1..^1];

static class E
{
  extension(C c)
  {
    public int Length => 3;
  }
  public static C Slice(this C c, int i, int j) => ...;
}

決定（LDM 2026-03-09）：是的，我們對經典與新擴充方法的處理方式完全相同。

延伸 Length 應該有助於擴散優化嗎？

C c = new C();
int[] i = [0, .. c]; // Uses Length, if available, to allocate the right size

決策（LDM 2026-03-09）：不，擴充功能不太可能以高效能的方式實作，因此對優化沒有幫助。

隱含索引器應該用於陣列型態或字串型別嗎？

我提出隱式索引器不會對這些情境有貢獻，因為只有在畸形的 corlib（缺少實例 Length， GetSubArray 或 GetSubstring）時才有可能。

決定（LDM/Mads 電子郵件 2026-04-07）：字串或陣列上不使用擴充索引器。

擴充索引器應該用在陣列類型或字串類型上嗎？

目前陣 列存取 與 字串存取 的規範與基準規則，意味著擴充索引器無法在陣列或字串上運作。
然而，宣告此類延伸索引器的聲明是被允許的。

int[] i = ...;
_ = i[new C()];

public static class E
{
    extension(int[] i)
    {
        public int this[C c] => throw null;
    }
}

string s = "...;
_ = s[new C()];

public static class E
{
    extension(int[] i)
    {
        public int this[C c] => throw null;
    }
}

注意：指標 元素存取 沒有問題，因為擴充參數可能不是指標類型。

決定（LDM/Mads 電子郵件 2026-04-07）：字串或陣列上不使用擴充索引器。