mirror of
https://github.com/pezkuwichain/pezkuwi-fellows.git
synced 2026-04-29 05:38:08 +00:00
deploy: 99e179cbc1
This commit is contained in:
+1
-1
@@ -2623,7 +2623,7 @@ enum TypeRef {
|
||||
<p>Every <code>Type</code> is composed of multiple different types. Each of these "sub types" can reference either a full <code>Type</code> again or reference one of the primitive types. This is where <code>TypeRef</code> becomes relevant as the type referencing information. To reference a <code>Type</code> in the type information, a unique identifier is used. As primitive types can be represented using a single byte, they are not put as separate types into the type information. Instead the primitive types are directly part of <code>TypeRef</code> to not require the overhead of referencing them in an extra <code>Type</code>. The special primitive type <code>Void</code> represents a type that encodes to nothing and can be decoded from nothing. As FRAME doesn't support <code>Compact</code> as primitive type it requires a more involved implementation to convert a FRAME type to a <code>Compact</code> primitive type. SCALE only supports <code>u8</code>, <code>u16</code>, <code>u32</code>, <code>u64</code> and <code>u128</code> as <code>Compact</code> which maps onto the primitive type declaration in the RFC. One special case is a <code>Compact</code> that wraps an empty <code>Tuple</code> which is expressed as primitive type <code>Void</code>.</p>
|
||||
<p>The <code>TypeDef</code> variants have the following meaning:</p>
|
||||
<ul>
|
||||
<li><code>Composite</code>: A <code>struct</code> like type that is composed of multiple different fields. Each <code>Field</code> can have its own type. A <code>Composite</code> with no fields is expressed as primitive type <code>Void</code>.</li>
|
||||
<li><code>Composite</code>: A <code>struct</code> like type that is composed of multiple different fields. Each <code>Field</code> can have its own type. The order of the fields is significant. A <code>Composite</code> with no fields is expressed as primitive type <code>Void</code>.</li>
|
||||
<li><code>Enumeration</code>: Stores a <code>EnumerationVariant</code>. A <code>EnumerationVariant</code> is a struct that is described by a name, an index and a vector of <code>Field</code>s, each of which can have it's own type. Typically <code>Enumeration</code>s have more than just one variant, and in those cases <code>Enumeration</code> will appear multiple times, each time with a different variant, in the type information. <code>Enumeration</code>s can become quite large, yet usually for decoding a type only one variant is required, therefore this design brings optimizations and helps reduce the size of the proof. An <code>Enumeration</code> with no variants is expressed as primitive type <code>Void</code>.</li>
|
||||
<li><code>Sequence</code>: A <code>vector</code> like type wrapping the given type.</li>
|
||||
<li><code>BitSequence</code>: A <code>vector</code> storing bits. <code>num_bytes</code> represents the size in bytes of the internal storage. If <code>least_significant_bit_first</code> is <code>true</code> the least significant bit is first, otherwise the most significant bit is first.</li>
|
||||
|
||||
@@ -400,7 +400,7 @@ enum TypeRef {
|
||||
<p>Every <code>Type</code> is composed of multiple different types. Each of these "sub types" can reference either a full <code>Type</code> again or reference one of the primitive types. This is where <code>TypeRef</code> becomes relevant as the type referencing information. To reference a <code>Type</code> in the type information, a unique identifier is used. As primitive types can be represented using a single byte, they are not put as separate types into the type information. Instead the primitive types are directly part of <code>TypeRef</code> to not require the overhead of referencing them in an extra <code>Type</code>. The special primitive type <code>Void</code> represents a type that encodes to nothing and can be decoded from nothing. As FRAME doesn't support <code>Compact</code> as primitive type it requires a more involved implementation to convert a FRAME type to a <code>Compact</code> primitive type. SCALE only supports <code>u8</code>, <code>u16</code>, <code>u32</code>, <code>u64</code> and <code>u128</code> as <code>Compact</code> which maps onto the primitive type declaration in the RFC. One special case is a <code>Compact</code> that wraps an empty <code>Tuple</code> which is expressed as primitive type <code>Void</code>.</p>
|
||||
<p>The <code>TypeDef</code> variants have the following meaning:</p>
|
||||
<ul>
|
||||
<li><code>Composite</code>: A <code>struct</code> like type that is composed of multiple different fields. Each <code>Field</code> can have its own type. A <code>Composite</code> with no fields is expressed as primitive type <code>Void</code>.</li>
|
||||
<li><code>Composite</code>: A <code>struct</code> like type that is composed of multiple different fields. Each <code>Field</code> can have its own type. The order of the fields is significant. A <code>Composite</code> with no fields is expressed as primitive type <code>Void</code>.</li>
|
||||
<li><code>Enumeration</code>: Stores a <code>EnumerationVariant</code>. A <code>EnumerationVariant</code> is a struct that is described by a name, an index and a vector of <code>Field</code>s, each of which can have it's own type. Typically <code>Enumeration</code>s have more than just one variant, and in those cases <code>Enumeration</code> will appear multiple times, each time with a different variant, in the type information. <code>Enumeration</code>s can become quite large, yet usually for decoding a type only one variant is required, therefore this design brings optimizations and helps reduce the size of the proof. An <code>Enumeration</code> with no variants is expressed as primitive type <code>Void</code>.</li>
|
||||
<li><code>Sequence</code>: A <code>vector</code> like type wrapping the given type.</li>
|
||||
<li><code>BitSequence</code>: A <code>vector</code> storing bits. <code>num_bytes</code> represents the size in bytes of the internal storage. If <code>least_significant_bit_first</code> is <code>true</code> the least significant bit is first, otherwise the most significant bit is first.</li>
|
||||
|
||||
+1
-1
File diff suppressed because one or more lines are too long
+1
-1
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user