Tuple Types

[sezna]

Tuple types, as they behave in Rust, should exist in our language. This issue tracks the parsing, type-checking, and code generation of tuple types.

[emilyaherbert]

Attempting this one...

[emilyaherbert]

Writing up a plan of attack:

1. Parsing. We will need to add support for n-ary tuple creation let tuple = (1,2,3,); as well as tuple access tuple.0 + tuple.1. This will involve adding a new test to the test cases and modify this (https://github.com/FuelLabs/sway/blob/master/core_lang/src/hll.pest. We will also need to add a case here:

   sway/core_lang/src/parse_tree/expression/mod.rs

   Line 770 in fc7b4fc

   a => {

   that parses the individual parts of the tuple and stores it in a new tuple variant:

   sway/core_lang/src/parse_tree/expression/mod.rs

   Line 25 in fc7b4fc

   pub enum Expression<'sc> {

2. Type checking. Type checking will require that we add a new case here:

   sway/core_lang/src/semantic_analysis/ast_node/expression/typed_expression.rs

   Line 179 in fc7b4fc

   a => {

   that checks the types of the individual parts of the tuple and creates a TypedExpression with a new tuple variant:

   sway/core_lang/src/semantic_analysis/ast_node/expression/typed_expression_variant.rs

   Line 13 in fc7b4fc

   pub(crate) enum TypedExpressionVariant<'sc> {

3. Code generation. Code generation, I am a little lost as to how to begin. I know that I will need to add a new case here:

   sway/core_lang/src/asm_generation/expression/mod.rs

   Line 284 in 1935aea

   a => {

   but after that I am a little lost...

[sezna]

In addition to these, there's also dead code analysis on the tuple type to identify unused tuple fields.

I think tuple types should just be serialized inline in memory on the stack, where e.g. x.1 accesses the 0th offset from the pointer x, x.2 accesses *x + sizeof(x.1) (offset to the second item) etc.

Alternatively, we could store every tuple field in a separate register and treat tuples as syntactic sugar over simply having multiple variables. I personally think the former idea, rather than the latter, is a cleaner and more sensible implementation.

[sezna]

Also, if we use the pointer and inline memory approach, we could reuse structs for dead code analysis and code generation since structs do the exact same thing.

[otrho]

Alternatively, we could store every tuple field in a separate register and treat tuples as syntactic sugar over simply having multiple variables. I personally think the former idea, rather than the latter, is a cleaner and more sensible implementation.

We should use the most sensible (i.e., not prematurely optimised) approach IMO, because breaking things out into registers can be done if needed by optimisation passes later. So I agree with using the former.

[emilyaherbert]

@canndrew is this closed?

[sezna]

I think it could remain open until destructuring is complete? Since tuple fields are inaccessible as of now, the tuples feature isn't fully ready

[sezna]

Closing and opening a new issue, against my own words above ^