Ad hoc type restriction

[Archie Cobbs]

Thanks for the comments - this is an interesting discussion. There are lots
of angles so I'll try to focus on one or two at a time.

Ethan McCue <ethan at mccue.dev> wrote:

> As I see it, your proposal #1 is already viable


Can you elaborate on how that would work?


> Maybe let's interrogate this from the other side: Why is this not easy to
> do? What friction points are essential (you do need to get a processor and
> put it on paths - what else?) and which are artificial? Clearly it's harder
> than a "normal library," why is that?


Here's a very simple, concrete example of what I want. To be honest, I'm
not sure whether this is just "difficult" or "impossible" today, but in
some sense that doesn't matter - either way, it's too hard!

WHAT I HAVE: Zillions of lines of code that look roughly like this
(continuing the previous @PhoneNumber example):

    public void dial(String pn) {
        Preconditions.checkArgument(pn != null &&
pn.matches(PhoneNumber.PATTERN));
        ... // do whatever
    }

WHAT I WANT: To be able to instead say this:

    public void dial(@PhoneNumber String number) {
        ... // do whatever
    }

AND have the following be true:

   - At compile time...
      - I get a warning or error if any code tries to invoke dial() with a
      "plain" String parameter, or assign a plain String to a  @PhoneNumber
      String
      - There is some well-defined, compiler-sanctioned way to validate a
      phone number, using custom logic I define, so I can assign it to
a @PhoneNumber
      String without said error/warning. Even if it involves
      @SuppressWarnings, I'll take it.
   - At runtime...
      - No explicit check of the number parameter is performed by the dial()
      method (efficiency)
      - The dial() method is guaranteed (modulo sneaky tricks) that number
      is always a valid phone number

Obviously you can replace @PhoneNumber with any other assertion. For
example: public void editProfile(@LoggedIn User user) { ... }

Is the above possible using the checker framework? I couldn't figure out
how, though that may be due to my own lack of ability.

But even if it is possible via checker framework or otherwise, I don't see
this being done in any widespread fashion, which seems like pretty strong
evidence that it's too hard.

Brian Goetz <brian.goetz at oracle.com> wrote:

> I just want to point out that there's a sort of "syntax error" in your
> proposal....Java provides annotations as a means of "structured comments"
> on declarations and type uses, but the Java language does not, and will
> not, impart any semantics to programs on the basis of annotations.


Right - it's like Java gives us sticky notes, but they are limited to just
being "developer notes", and the compiler support for plugging in custom
automation using those notes (annotation processors) is too limited to
implement the above idea.

So (side note) in theory this whole idea could be redirected toward
expanding compiler "plug-in" support instead of "annotation hacking".

But I think it's OK for certain "sticky notes" to be understood by the
compiler, and have the compiler offer corresponding assistance in verifying
them (which it is already doing - see below). I also agree that having
annotations affect the generated bytecode ("runtime semantics") is a big
step beyond that, but maybe that's not necessary in this case.

If you mean that the compiler actually is going to get into the act,
> though, then this is not an annotation-driven feature, this is a full-blown
> language feature and should be thought of accordingly.  I know its tempting
> to view annos as a "shortcut" to language features, but if something has
> semantics, its part of the language, and sadly that means no shortcuts.


I agree in principle. Unfortunately that sounds like something that would
take a long time to happen.

Moreover, there is at least one counter-example to your claim: @Override.
That annotation is not just a "developer sticky note" - it triggers a
compile-time error if what it asserts is not true - precisely what we want
here.

Just curious... What was the thinking that allowed @Override to be an
exception to the rule, and why would that thinking no longer apply?

And after all, who doesn't love @Override ? :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251014/f10ec3ed/attachment.htm>