Member Patterns -- the bikeshed

[Guy Steele]

Well, there has not been a lot of traffic during the last week and a half on these topics (“syntax”), so I will jump in and offer my two cents’ worth.

On Apr 4, 2024, at 1:11 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

There's obviously some more discussion coming about "what is a pattern", but let me summarize the points on which we've asked for syntax feedback, and make another call (I can't believe I have to ask) for opinions here.


Use-site syntax.  The document catalogs the use-site syntax for deconstruction, static, and bound/unbound instance pattern uses.  I don't think any of these are controversial.  (There are details to be captured, such as qualifier inference, but I think the overall scheme here is sound.)

I do, too.

Identifying a member as a pattern.  The proposed approach is a "pattern" keyword for all pattern kinds, but there are other choices.

I like using `pattern` as a (necessarily contextual) keyword.

Method-style (multiple return) vs inverse-style.  I thought the document made it entirely clear that the method-style declaration was going to be a loser, but I guess we had more work to do there.

Inverse style is good.

Position of match candidate.  Here, there is a reasonable menu of choices:

    static<T> pattern Optional<T> of(T t)
    static<T> pattern<Optional<T>> of(T t)
    static<T> pattern(Optional<T> that) of(T t)
    static<T> pattern of(T t) for Optional<T>

I don’t feel strongly about this choice.

Naming of match candidate.  The document proposes to use `that` uniformly.

I think using `that` uniformly is a good choice.

Body types.  There is the broad choice of "imperative vs functional"; within that, there are choices about "implicit failure" or "implicit success."  There is also how we indicate success and failure.  The suggested approach is functional, implicit failure, return means fail, success is indicated by `match patternName(BINDINGS)`.

I am all for this.

If we choose to provide the “special convenience feature” to support the imperative style, I would suggest that it be simply `match;` and not `match patternName;` because its reason for existence is to abbreviate.

Exhaustiveness.  The document proposes `case` as a modifier for patterns that form exhaustive sets.  This isn't great, but note that this feature is likely to be used less often than we probably think, as new code will likely steer towards sealed classes and deconstruction patterns.

Agreed, not great, but I think we could live with it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240416/af5c196b/attachment.htm>