Using the bare name of a generic type within itself

DevAndArtist · 2019-05-23T13:15:07.099Z

Nevin:

Within a generic type, uses of the bare name of that type still mean the same thing as “ Self ” will with SE–0068, and they cannot have their generic parameters inferred from context like they can elsewhere outside that type.

Thank your summing it up for me. This is, from my perspective at least, aligned with the generic type that omits its generic type parameter list in extensions. For example we can just write extension Result { ... } and do not need to write the generic types with all their constraints over and over again. I can kind of understand why inside the generic type the bare type always is viewed as Self instead of Self with different generic types inferred from some context.

Would be interesting to see if the core team thinks that it would be reasonable to change that restriction a little.

hamishknight · 2019-05-23T13:33:21.323Z

In the comments of SR-4155 it looks like the Swift team would be open to removing this "feature", but it would require an evolution proposal.

DevAndArtist · 2019-05-23T13:37:20.823Z

Thats a good sign especially now that we have Self we can even cover some scenarios where this feature was used and simply migrate to Self if required.

Nevin · 2019-05-23T13:42:07.301Z

DevAndArtist:

For example we can just write extension Result { ... } and do not need to write the generic types with all their constraints over and over again. I can kind of understand why inside the generic type the bare type always is viewed as Self instead of Self with different generic types inferred from some context.

I am not proposing any change to how extensions are introduced, only to how the unadorned name of the generic type is treated within an extension (or the main body) of that type itself.

Now, it would obviously be source-breaking to entirely eliminate the current behavior, though migration to use Self could be done automatically. However, I think we can avoid most of that by simply making the current behavior a fallback to be used in case the generic parameters cannot otherwise be inferred.

That is, we can say “Within a generic type, when the bare name of that type is used, the generic parameters are inferred from context, and the lowest-priority possibility is to use the same generic parameters as the type we are currently inside.”

That way, the current behavior still works (you can use the bare name to mean Self), but also the desired behavior works too (you can write let y = Optional(x) for any x).

There is one narrow scenario where the behavior would change with this, and that is when the generic parameter of Self is a supertype of the inferred type:

protocol Foo {}
extension Int: Foo {}

extension Optional where Wrapped == Foo {
  func foo() {
    let x = 1
    let y = Optional(x)
  }
}

Today, y is a Foo?, whereas with this change it would become an Int?.

Luckily, with SE–0068, the fix to keep the existing behavior is simple: let y = Self(x). This is the same automatable migration that would happen if the existing behavior were entirely eliminated, but it will only be necessary in a tiny fraction of situations if we keep that behavior as a fallback.

jrose · 2019-05-23T15:38:03.575Z

There's an actual reason why it exists, one contrived case where naming the parameters correctly may not be possible, but I can't produce it right now and it might have to do with shadowing anyway, which means it's "your" own fault. I'd personally be glad if someone attempted to get rid of this, but unfortunately that is definitely a source-breaking change, and so we'd probably have to do it next time we want to introduce a new -swift-version. And even then we'd want to be careful about it.

Nevin · 2019-05-23T16:25:55.690Z

hamishknight:

In the comments of SR-4155 it looks like the Swift team would be open to removing this "feature", but it would require an evolution proposal.

Good find, thanks!

jrose:

There's an actual reason why it exists, one contrived case where naming the parameters correctly may not be possible, but I can't produce it right now and it might have to do with shadowing anyway, which means it's "your" own fault.

…but with SE–0068, that case can now be spelled Self, right?

• • •

Also, in addition to the original problem of having to write out the generic parameters longhand, I think the most recent example I posted shows that the current behavior is not only troublesome when writing code, but also when reading code, as it harms clarity at the point of use:

extension Optional where Wrapped == Any {
  func foo() {
    let x = 1
    let y = Optional(x)
  }
}

Any reasonable Swift developer, upon seeing this code, should expect that y is an Int?, just like it would be anywhere else. But—surprise!—it’s actually an Any?.

jrose · 2019-05-23T16:28:14.943Z

Aha, I remember the terrible example:

struct Outer<Element> {
  struct Inner<Element> {
    func produceOuter() -> Outer {
      // …
    }
  }
  // …
}

This looks especially contrived, but if Outer and Inner are both Collections they don't have a choice about the name "Element". It's still something you can work around with a typealias, though, even if Self isn't sufficient.

Nevin · 2019-05-23T16:31:05.987Z

jrose:

This looks especially contrived, but if Outer and Inner are both Collections they don't have a choice about the name "Element". It's still something you can work around with a typealias, though, even if Self isn't sufficient.

Ah, very nice!

Still, with the idea of “Use the current behavior as a fallback in case the generic parameters cannot be inferred”, that example would remain workable as written, with no changes.

Edit:

Also, there are still other things that are equally difficult to write already, which the shorthand does not help with and therefore typealiases are necessary:

struct Outer<A, B> {
  typealias OuterA = A
  typealias OuterB = B
  
  struct Inner<A, B> {
    func invertedOuter() -> Outer<OuterB, OuterA> {
      // …
    }
  }
}

It might be interesting to consider a way to reference generic parameter types à la “Outer.A”, but that’s beyond the scope of what I’m looking to accomplish here.

fclout · 2019-05-23T17:15:26.688Z

Keep in mind that Self is not the same as the explicit, statically-known type when you’re dealing with classes.

DevAndArtist · 2019-05-23T17:56:32.092Z

Here comes qualified lookup for rescue, no?

struct Outer<Element> {
  struct Inner<Element> {
    func testElementTypes() -> Bool {
      return Element is Outer.Element // qualified lookup (not possible yet)
    } 
  }
}

Allow Member Lookup to Find Generic Parameters Pitches

Hello dear Swift community, I waited with this pitch until the forum finally went live. Last year there were some topic regarding protocol nesting where this idea was born from. Mainly this idea is meant to disambigute similar named types, but there are also other areas where this aligned behavior would come to a benifit. Here a few snippets where I see this behavior as useful. // Future direction: class Generic<Element> { protocol P { // `Element` is not captured by P, but could allow the…

Nevin · 2019-05-23T18:13:48.934Z

fclout:

Keep in mind that Self is not the same as the explicit, statically-known type when you’re dealing with classes.

Excellent point.

I think this pretty well cements that we need to keep the current behavior around, at least for situations where the generic parameters cannot otherwise be inferred.

However, I still maintain that when those parameters can be inferred, they should be inferred just as they would anywhere else.

Does anyone see a compelling reason not to pursue a course of action whereby, inside a generic type, we allow the bare name of that type to participate in type inference for its generic parameters, with a lowest-priority fallback of using the existing behavior if no other solution is found?

jrose · 2019-05-23T18:20:15.213Z

I remain leery of this fallback thing because it doesn't actually describe what the type checker should do in practice. What if the type name is mentioned twice in the same expression? Do you apply the fallback to one of them but not the other and try again? Or both of them at once? (I bet I can contrive a sufficiently bad example such that these two choices give different answers, but I'm also pretty sure that won't ever come up in real code. The point is that "as a fallback" isn't an implementation plan.)

Nevin · 2019-05-23T18:24:06.575Z

Well, we can already use a bare generic type repeatedly in the same expression, and each will infer its generic arguments independently:

let tuple = (Optional(1), Optional("a"))
print(type(of: tuple))    // (Optional<Int>, Optional<String>)

I would expect that same behavior to work everywhere. And “as a fallback” here really means “Put this into the typechecker as a possibility, but make it rank really low so if any other possibility is valid, this one won’t be chosen.”

jrose · 2019-05-23T18:38:18.163Z

In your example, the two arguments are independent, but that isn't always true:

typealias UniformPair<Element> = (Element, Element)
let tuple: UniformPair = (Optional(1), Optional("a")) // error

I realize this isn't sufficiently contrived to run into the actual problem, but "rank it really low" doesn't handle the "what if two different things are ranked really low" problem.

Slava_Pestov · 2019-05-23T20:13:29.406Z

I would be very happy if someone put together a proposal for this. This is on my short list of breaking language changes I'd still like to see at some point:

Remove bare generic type behavior (this)
Remove implicit 'nil' initial value for Optional-typed variables
Remove AnyObject dynamic dispatch
Remove implicit conformance to Hashable for enums with no payload cases
Remove label-shuffling tuple conversions

anandabits · 2019-05-23T20:19:58.190Z

That’s a nice list. It would be cool if these could happen eventually.

GarthSnyder · 2019-05-23T21:19:02.808Z

I may just be having an off day, but I'm not seeing the fundamental value of having any special inference behavior within generic types.

@jrose's motivating example (inability to name a parameter type when shadowed by a same-named inner generic parameter) seems like an uncommon case and one that's easily addressed with a typealias.

The motivation mentioned by @AlexanderM (the repetitiousness of having to fully-qualify generic return types) doesn't seem so terrible, either. Why should the notation for the return of a Self-typed generic be any different from the return of a generic type anywhere else in Swift? If you really can't stand to repeatedly name the generic parameter types, just create a typealias.

Rather than piling backup behaviors or special cases on top of the existing special case, it seems like the proper solution would be to eliminate the original exception.

Nevin · 2019-05-23T22:39:34.373Z

GarthSnyder:

Rather than piling backup behaviors or special cases on top of the existing special case, it seems like the proper solution would be to eliminate the original exception.

Well, Jordan is most likely right about the type checker with respect to expressions, so perhaps the behavior should be removed entirely there.

However, I think that declarations within a generic type (eg. properties, methods, nested types, and so forth) should still be able to use the shorthand when specifying their own types (including the types of their arguments, return values, and generic parameters). It is convenient, reads well, and I don’t see any active harm to keeping it.

By contrast, the initializer behavior I described earlier does strike me as harmful, so I’d be happy to see it removed.

jrose · 2019-05-23T23:36:08.698Z

It was originally added because C++ has it and it's convenient for the purposes Nevin mentions, though of course C++ didn't support inference of type arguments at the time it was added to C++. I don't think it was ever intended as the only way to spell something. @Douglas_Gregor might remember if there was more to it than that.

Douglas_Gregor · 2019-05-30T16:52:12.794Z

That’s pretty much it. It seemed like a nice convenience when I cargo-culture it years ago (we didn’t have the general Self at the time). I’d love to phase this out of the language.