SE-0299 (second review): Extending Static Member Lookup in Generic Contexts

Evolution Proposal Reviews
21

Yes, the core team has accepted this proposal, with the revision suggested by John at the start of the thread.

4 Likes
22

Thought I'd drop a quick note to highlight a possible failure case for this proposal's implementation, described by [SR-15853] Re: SE-0299: Static member lookup fails in type that has two tuples. · Issue #58127 · apple/swift · GitHub.

23

IIUC the code you've posted in that bug doesn't introduce the proper generic context for the static members to be resolved under SE-0299, since Model.a.y and Model.b.y are of existential type Tint rather than generic type constrained to Tint. Changing the definition of Model to the following allows this to type check:

struct Model<T: Tint> {
    let a:   (x: String, y: T)?
    let b:   (x: String, y: T)?
}

ETA: though this still appears to be a bug with implicit member syntax in general since this works with the non-tuple and single-tuple versions. I just don't think it's related to SE-0299 specifically.

24

Thanks, that makes some sense. Though with that said, if not under SE-0299's implementation, perhaps you can clarify for me how the swift compiler resolves the member type of the existential, then? Note that the requirements on how the members should be declared on the protocol extension are exactly in line with SE-0299.

1 Like
25

Actually, after looking into it a bit further, I take it back—I think this is related to SE-0299. This sort of inference through an existential was not permitted prior. I was confusing it with the behavior that allowed the result of a chain to be a subtype of the overall result type for subclasses.

cc @xedin is the lookup behavior in an existential context intended here?

26

SR-15853 looks like a bug to me which was been fixed recently, I have tried with 02/03 snapshot of main and the example type-checks correctly with that toolchain.

1 Like
27

Ah, I didn't realize that SE-0299 was also intended to work in existential contexts—I thought it was restricted only to generic contexts. Perhaps the proposal title/body should be adjusted to make it clear that this use case is supported?

28

I understand what you mean although it took me a bit :) Strictly speaking it's indeed not to the letter of the proposal since it would infer a base type not based the generic conformance requirement of the result, but directly from the protocol of the existential type, so maybe it indeed makes sense to document that somehow...

1 Like