[swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[T.J. Usiyan]

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> のメッセージ:
>
> > 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 <pyry.jahkola at iki.fi> 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 <
> swift-evolution at swift.org> wrote:
> >>>
> >>> on Thu Jun 23 2016, Slava Pestov <swift-evolution at 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.
> >>>
> >>> SGTM.  I've always found this shorthand to be somewhat surprising,
> >>> including in C++ where (IIUC) it originated.
> >>>
> >>>
> >>> --
> >>> Dave
> >>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161011/b790f56c/attachment.html>