Painful +1. I use the first one a whole lot in a project and it is going to get ugly. That said… I can see how it is tricky in a way that doesn't really pay off for most people. Removing the first feature might even be necessary for what I hope will ease the ugly. I don't see "Default generic arguments" being easy to reason about alongside the first feature.
TJ On Tue, Oct 11, 2016 at 9:30 PM, Robert Widmann via swift-evolution < [email protected]> wrote: > +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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
