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

[Robert Widmann]

+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