+1. I don't use this feature at all and (by extension) don't think there are many situations where it's useful.
~Robert Widmann 2016/10/11 18:03、Slava Pestov via swift-evolution <[email protected]> のメッセージ: > I could if there’s interest. Since we intend on maintaining source > compatibility, it will not result in a simpler implementation, though, since > we’ll need to keep the old code path around for Swift 3 mode. Still worth it? > > Slava > >> On Oct 11, 2016, at 1:58 PM, Pyry Jahkola <[email protected]> wrote: >> >> I was reminded of this proposal which seems like an obvious win in clarity. >> Still planning to submit it, Slava? >> >> ― Pyry >> >>> On 28 Jun 2016, at 21:13, Dave Abrahams via swift-evolution >>> <[email protected]> wrote: >>> >>> on Thu Jun 23 2016, Slava Pestov <[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. >>> >>> SGTM. I've always found this shorthand to be somewhat surprising, >>> including in C++ where (IIUC) it originated. >>> >>> >>> -- >>> Dave >> > > _______________________________________________ > 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
