From the refrat (5.5) we have our specification: \section{Initialization} An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the object being initialized. An expression used in an \nonterm{initializer-list} is treated as being cast to the type of the aggregate member that it initializes. In either case the cast must have a single unambiguous interpretation\index{interpretations}. Steps: - add a member function "void Resolver::visit( SynTree::DeclStmt *declStmt )"; for each DeclStmt: - do what you need to do to establish correspondences between expressions in the initializer and pieces of the object to be initialized - for each initializer expression, construct a cast expression that casts the value of the expression to the type of the corresponding sub-object - invoke the resolver recursively on each cast expression; it's an invariant of the resolver that attempting to resolve a cast expression results either in a single resolved expression (corresponding to the unambiguous interpretation referred to above) or a thrown SemanticError. - construct a new initializer from the resolved expressions You'll undoubtedly have to play with the CodeGen stuff a bit; I hacked it to spit out unresolved initializers for file-scope declarations so that real programs would compile. You'll want to make sure that resolved initializers for all declarations are being generated. ------ More recent email: (I am quoted; Richard is the responder) > As far as I'm aware, the only way that I could currently get the correct > results from the unification engine is by feeding it an expression that > looks like "?=?( ((struct Y)x.y).a, 10 )", then picking out the pieces that > I need (namely the correct choice for a). Does this seem like a reasonable > approach to solve this problem? No, unfortunately. Initialization isn't being rewritten as assignment, so you shouldn't allow the particular selection of assignment operators that happen to be in scope (and which may include user-defined operators) to guide the type resolution. I don't think there is any way to rewrite an initializer as a single expression and have the resolver just do the right thing. I see the algorithm as: For each alternative interpretation of the designator: Construct an expression that casts the initializer to the type of the designator Construct an AlternativeFinder and use it to find the lowest cost interpretation of the expression Add this interpretation to a list of possibilities Go through the list of possibilities and pick the lowest cost As with many things in the resolver, it's conceptually simple but the implementation may be a bit of a pain. It fits in with functions like findSingleExpression, findIntegralExpression in Resolver.cc, although it will be significantly more complicated than any of the existing ones.