It's counterintuitive as hell and a constant source of bugs:
struct ast_list_type with confusing rules about which combination of field values means what.struct type_array again, meanings of field value combinations are confusing. Additionally, the struct has a field bool expandable, which actually is used in quite a lot of places. I don't think that should be a part of the checked type.The actual state of things is that arrays come with 3 special kinds, unbounded, expandable and contextual. Expandability is a property of the array expression, not the type. (Un)boundedness is a property of the type, expressions of unbounded array types can't even exist. Contextuality is a property of the type, but depending on how we're going to implement it in the end, it may be relevant to the expession as well. Whatever representation will replace the current one, those special cases need to be stored in the right places, and stored explicitly.
The representation used for slice types should be separate, and simpler.
We should also make these same changes in hare::parse.
Expandability is a property of the array expression, not the type.
This currently isn't true. Making it a property of the expression is probably the correct thing to do, but the spec will need to be updated.
Contextuality is a property of the type, but depending on how we're going to implement it in the end, it may be relevant to the expression as well.
Related: #886. We should probably figure that out first before we make any changes here.
Bor Grošelj Simić referenced this ticket in commit 42573fc.
Bor Grošelj Simić referenced this ticket in commit c0db5b1.