> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu <xiaodi...@gmail.com> 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
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
