RFC-0038：將版面配置與限制分開

拒絕理由

在起草及公開討論此提案時，我們一致認為應一次性考慮語法變更，而非逐一考量 (另請參閱 RFC-0039)。我們也希望由一人擔任語法仲裁者，而非由委員會設計，以免發生風險。

最後，這項提案已由 RFC-0050 取代，因為後者符合兩項條件。

摘要

我們建議改變語法，以便說明版面配置與限制條件之間的差異。

提振精神

版面配置與限制

快速：

• 如果兩種型別的版面配置不同，就無法從一種型別轉換至另一種型別，反之亦然 (至少不容易)。
• 版面配置會說明位元組的排列方式，而非解讀方式。
• 類型的限制是指在編碼/解碼期間執行的驗證步驟。
• 限制條件可能會演變，只要作者受到的限制比讀者多，兩者就會相容。

相同語法用於不同事物

版面配置不同的類型，以及版面配置相同 (但限制條件不同的) 的類型看起來都很相似。

相同的版面配置：

• vector<T>:6或vector<T>:10
• T?，其中 T 是 union、vector 或 string
• handle、handle<vmo> 或 handle<channel>

不同的版面配置：

• array<T>:6對array<T>:10
• S?，其中 S 為 struct

設計

對齊語法

layout:constraint

對於類型，也就是控制版面配置的任何項目都會放在冒號之前，控制限制的項目則會放在冒號之後。

建議的變更：

    array<T>:N    becomes            array<T, N>

    S?            becomes            box<S>:nullable       (S is a struct)

    T?            becomes            T:nullable            (T is a vector, or union)

    string        is an alias for    vector<uint8>:utf8

    handle<K>     becomes            handle:K

注意：

• 並非所有限制都適用於所有類型，例如無法將 struct 標示為可為空值。
• 並非所有項目都能納入箱中，最初只有結構體可以 (目標是變更語法，而非引入更多可選項目)。

人體工學

本提案透過語法向開發人員傳達 ABI 影響，以改善人因工程。

說明文件和範例

至少：

• 語言規格
• 文法
• 使用結構體的範例

回溯相容性

這不是源碼層級的回溯相容性。