Thanks John! I’ll find a workaround or just punt on this QoI work for now.
Dave > On Sep 24, 2017, at 23:06, John McCall <rjmcc...@apple.com> wrote: > >> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> Hi Robert, >> >> As a prerequisite to some other hacking I’m doing, I have an experimental >> implementation of value semantics; where (among other details), all >> functions have a bit in ExtInfo that denotes whether the function has >> enforced value semantics or not. As a matter of polish, I’d like the >> following code to work: >> >> // reference semantic context >> someValueTypeArray.sort({ >> // hasValueSemantics ExtInfo bit propagates from the >> // parameter type of sort() to the ClosureExpr type >> }) >> >> Hence the desire to have the closure’s type be a disjunction between two >> FunctionTypes, one where the “hasValueSemantics” bit is set, and one where >> it is not. If there is a better way to do this, I’m open. :-) > > The working plan with closure type-checking is that we'll add a "this is a > closure type" constraint to the type-checker where, instead of having to pick > a concretely-structured function type during CSGen, we'll create a fresh type > variable and say that its type is required to be structured compatibly with > whatever information we've derived from the closure. Contextual information > would then naturally flow from the context to the closure's type. The > constraint solver would default the function type from the encoded closure > structure of the constraint if it could prove that no other constraint > applied. > > If that was implemented, we'd be able to propagate arbitrary function-type > structure from the context instead of having to eagerly create highly-complex > constraint systems whenever we encountered a closure. > > John. > > >> >> Thanks, >> Dave >> >> >>> On Sep 23, 2017, at 20:11, Robert Widmann via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>> >>> >>>> On Sep 23, 2017, at 3:39 PM, David Zarzycki via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>> >>>> Hello, >>>> >>>> I’m trying to replace the explicit FunctionType returned by >>>> visitClosureExpr() in CSGen.cpp with a type variable; and ultimately a >>>> disjunction of two FunctionTypes with different ExtInfo flags set (one >>>> favored, one not). >>> >>> I really don’t recommend doing this. Even the current late-binding of a >>> proper function type in closure inference is an artifact of the old >>> function type representation that needs to go away (you’re probably running >>> into parameter inference doing weird things which is a symptom of the >>> larger problem). What does it matter that the two function types have >>> different ExtInfo? What are you trying to do here? >>> >>> ~Robert Widmann >>> >>>> >>>> Thanks, >>>> Dave >>>> _______________________________________________ >>>> swift-dev mailing list >>>> swift-dev@swift.org <mailto:swift-dev@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-dev >>>> <https://lists.swift.org/mailman/listinfo/swift-dev> >>> >>> _______________________________________________ >>> swift-dev mailing list >>> swift-dev@swift.org <mailto:swift-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-dev >>> <https://lists.swift.org/mailman/listinfo/swift-dev> >> >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
