Placeholder types

Evolution Pitches
82

So, I don't personally think that _.zero should mean the same thing as .zero. That was my initial reaction to the _.zero form ("oh, that would just be another way to spell implicit member expressions, hmm"), but as I worked on the implementation I realized why they weren't immediately equivalent. I mentioned them in the update post in case anyone had read the earlier posts and come away with the impression that those two expressions would be equivalent.

I only brought it up again because of your suggestion that there's no logical grounds to allow _.self but not permit other members to hang off of _. I was trying (not super well, obviously) to communicate that:

  • There are logical reasons, based solely on current type inference rules (which this proposal does not modify), why _.self would work but, say, _.zero wouldn't, and
  • If there's a common intuition that _.zero should work, despite the above inference rules, then there are potentially ways to update those inference rules to allow such expressions to work as 'expected'.
1 Like
83

The proposal and implementation have both been updated to reflect the decision to subset out top-level placeholders from this feature and leave them as a potential future direction pending further use and discussion of the feature.

3 Likes
84

Is this going to help with nested tuple destructuring? Swift is unable to fully destructure a nested tuple, for example when passing a closure to a Sequence.map where the sequence element is something like (A, (B, C)); to achieve a "faux-destructing" you can do something like this:

typealias __ = Any

(1...10)
    .map {
        (
            $0,
            (
                "\($0)",
                $0 > 5
            )
        )
    }
    .map { (intValue, x: (__, boolValue: Bool)) in
        x.boolValue ? intValue : 0
    }

This works, I guess, because (Int, (Any, Bool)) is a supertype of (Int, (String, Bool)). Will I be able, with this proposal, to skip the Any and the Bool explicit type annotation and write something like this?

.map { (intValue, x: (_, boolValue: _)) in
    x.boolValue ? intValue : 0
}
85

@ExFalsoQuodlibet I just ran your example through the prototype implementation, and the following code compiles without issue!

_ = (1...10)
    .map {
        (
            $0,
            (
                "\($0)",
                $0 > 5
            )
        )
    }
    .map { (intValue, x: (_, boolValue: _)) in
        x.boolValue ? intValue : 0
    }
86

Thank you so much! Now I'm even more supportive of this :smiley:

1 Like
87

Thank you! Do you mind if I include your example as a test case for the feature, under the Swift project license?

88

I don’t mind at all, please do it :blush:

1 Like
89

This proposal has been scheduled for review as SE-0315. Review will begin on June 21.

11 Likes
90

That's great news!

91

I don’t think this can be considered valid: The first line of code is sufficient for the type inference to figure out that the placeholder should be Int, so anyArray = ["string"] should not be allowed…

1 Like
92

@wilsony Sorry if the text above was unclear—this was meant as an example of a proposed alternative meaning for _ in types (which this proposal rejects). Under this proposal the quoted code is indeed invalid.

93

Thank you for clarifying!

---- Replied Message ----

From | Frederick Kellison-Linn via Swift Forumsswift@discoursemail.com |

| Jumhyn Frederick Kellison-Linn
June 10 |

  • | - |

@Xkinler Sorry if the text above was unclear—this was meant as an example of a proposed alternative meaning for _ one types which this proposal rejects. Under this proposal the quoted code is indeed invalid.

94

I just built this and wow! this is really a good first step in fixing some long standing problems. Thanks for taking this on.

95

That's great to hear @Philippe_Hausler! Though I suspect you meant this feedback to make its way over to the review thread. :slightly_smiling_face: