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.