Telling the totality story

[Brian Goetz]

>
> So, I think the main thing we can control about the story is the 
> terminology.  I think part of what people find confusing is the use of 
> the term "total", since that's a math-y term, and also it collides 
> with "exhaustive", which is similar but not entirely coincident.

One concept we might want to appeal to here is the notion of a "pattern 
that isn't really asking a question".  This is still going to depend on 
the static type of the target, but rather than appealing to a 
mathematical term like "total" or "statically total", perhaps something 
like "a vacuous pattern" (much like the statement "all hairy hairless 
apes are green" is vacuously true), or a "self evident" pattern, or "an 
unconditional pattern" or an "effectively any" pattern or a "constant 
pattern" [1], or an "undiscerning pattern", or ...

Recall that the total / effectively any / unconditional / vacuous 
patterns are:

  - `var x`
  - an any pattern `_` , if we ever have it
  - A type pattern `T t`, when applied to a target `U <: T`.

All other patterns at least ask some question.

(FWIW, what the spec currently does is: syntactic patterns undergo a 
resolution to a runtime pattern as part of type analysis.  So given a 
target type of Object, the pattern `Object o` *resolves* to an any 
pattern, whereas `String s` resolves to the type pattern.  May or may 
not be helpful.)

Perhaps if we had a term for "a pattern that is not asking anything", 
this may help to frame the story better.


[1] Currently, we've been calling patterns that are just a literal (if 
we ever have them) "constant patterns", but we could also call those 
"literal patterns", if we wanted to reserve "constant" as a modifier to 
mean that the pattern is a constant.  Or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220305/a7d01631/attachment-0001.htm>