Changes in src/initialization.txt [843054c2:9cb8e88d]

File:

• src/initialization.txt (modified) (1 diff)

src/initialization.txt

@@ -34 +34 @@
 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.
+
+
+