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

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.
-
-
-