Sorry, it's I who is saying things all wrong. I meant to ask, is it feasible to keep both behaviors but have #2 "win" over #1, instead of getting rid of behavior #1 entirely?
On Thu, Jun 23, 2016 at 15:30 Slava Pestov <[email protected]> wrote: > On Jun 23, 2016, at 1:27 PM, Xiaodi Wu <[email protected]> wrote: > > When you mention the difficulty of an alternative, is that to say that > it's not feasible for the GenericBox in the last example to be resolved as > GenericBox<T>? From an end-user point of view, that seems to be the most > sensible behavior. > > > With my proposed change, GenericBox would be resolved as GenericBox<T> in > the last example. Right now it fails to type check. > > Here is an example that works right now, but would not work with my > proposed change: > > struct GenericBox<Contents> { > // Currently Swift resolves this as ‘GenericBox<Contents>’ > // With the new rule, we cannot infer the parameter, because there’s no > expression to infer it from > func combine(other: GenericBox) { > … > } > } > > Basically the meaning of ‘GenericBox’ right now depends on whether it > appears inside its own definition or extension thereof, or not. The > behavior when it appears elsewhere is more general — we infer the > parameters from the surrounding expression, instead of assuming they’re > equal to the context parameters. > > This is a subtle change — definitely let me know if I’m not explaining it > well. > > Slava > > On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution < > [email protected]> wrote: > >> Simpler interpretation of a reference to a generic type with no arguments >> >> - Proposal: SE-9999 >> >> <https://github.com/slavapestov/swift-evolution/blob/silly-proposals/proposals/9999-simplify-unbound-generic-type.md> >> - Author: Slava Pestov <https://github.com/slavapestov> >> - Status: Awaiting review >> - Review manager: TBD >> >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#introduction> >> Introduction >> >> This proposal cleans up the semantics of a reference to a generic type >> when no generic arguments are applied. >> >> Swift-evolution thread: Discussion thread topic for that proposal >> <http://news.gmane.org/gmane.comp.lang.swift.evolution> >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#motivation> >> Motivation >> >> Right now, we allow a generic type to be referenced with no generic >> arguments applied in a handful of special cases. The two primary rules here >> are the following: >> >> - >> >> If the scope from which the reference is made is nested inside the >> definition of the type or an extension thereof, omitting generic arguments >> just means to implicitly apply the arguments from context. >> >> For example, >> >> struct GenericBox<Contents> { >> let contents: Contents >> >> // Equivalent to: func clone() -> GenericBox<Contents> >> func clone() -> GenericBox { >> return GenericBox(contents: contents) >> } >> } >> extension GenericBox { >> func print() { >> // Equivalent to: let cloned: GenericBox<Contents> >> let cloned: GenericBox = clone() >> print(cloned.contents) >> } >> } >> >> >> - >> >> If the type is referenced from an unrelated scope, we attempt to >> infer the generic parameters. >> >> For example, >> >> func makeABox() -> GenericBox<Int> { >> // Equivalent to: GenericBox<Int>(contents: 123) >> return GenericBox(contents: 123) >> } >> >> The problem appears when the user expects the second behavior, but >> instead encounters the first. For example, the following does not type >> check: >> >> extension GenericBox { >> >> func transform<T>(f: Contents -> T) -> GenericBox<T> { >> // We resolve 'GenericBox' as 'GenericBox<Contents>', rather than >> // inferring the type parameter >> return GenericBox(contents: f(contents)) >> } >> } >> >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#proposed-solution>Proposed >> solution >> >> The proposed solution is to remove the first rule altogether. If the >> generic parameters cannot be inferred from context, they must be specified >> explicitly with the usual Type<Args...> syntax. >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#detailed-design>Detailed >> design >> >> This really just involves removing an existing piece of logic from the >> type resolver code. >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#impact-on-existing-code>Impact >> on existing code >> >> This will have a small impact on existing code that uses a pattern >> similar to the above. >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#alternatives-considered>Alternatives >> considered >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#status-quo>Status >> quo >> >> We could keep the current behavior, but one can argue it is not very >> useful, and adds a special case where one is not needed. >> >> <https://github.com/slavapestov/swift-evolution/tree/silly-proposals/proposals#more-complex-inference-of-generic-parameters>More >> complex inference of generic parameters >> We could attempt to unify the two rules for resolving a reference to a >> generic type with no arguments, however this presents theoretical >> difficulties with our constraint solver design. Even if it were easy to >> implement, it would increase type checking type by creating new >> possibilities to consider, with very little actual benefit. >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
