id	summary	reporter	owner	description	type	status	priority	component	version	resolution	keywords	cc
128	Rearchitect TupleType	a3moss		"Rob left some comments on the design of the `TupleType` AST node suggesting some different design directions (see `src/SynTree/TupleType.cc` or `src/AST/Type.cpp`). The gist is that the relationship between the `types` and `members` fields is non-trivial, and could be factored out more cleanly.

Comment verbatim below:

> This is very awkward. `TupleType` should contain objects so that members can 
> be named, but if they don't have an initializer node then they end up 
> getting constructors, which end up being inserted causing problems. This 
> happens because the object decls have to be visited so that their types are 
> kept in sync with the types list here. Ultimately, the types list here 
> should be eliminated and perhaps replaced with a list-view of the object 
> types list, but I digress. The temporary solution here is to make a 
> `ListInit` with `maybeConstructed = false`, that way even when the object is 
> visited, it is never constructed. Ultimately, a better solution might be 
> either:
>
> a) to separate `TupleType` from its declarations, into `TupleDecl` and 
> `Tuple{Inst?}Type`, ala `StructDecl` and `StructInstType`
>
> b) separate initializer nodes better, e.g. add a `MaybeConstructed` node 
> that is replaced by `genInit`, rather than what currently exists in a `bool`"	enhancement	closed	minor	cfa-cc	1.0	fixed