Long or Short syntax for Records wrt Guards

[Stephen Colebourne]

Syntax, not semantics? I'm raising this because sometimes a focus on
one syntax can colour views on what the right semantic approach is,
eg. with guards

The proposed short syntax for records is:

record Person(@Foo String surname, String forename, LocalDate dob)
implements NameProvider {
  public String name() {...}
}

The long syntax is:

record Person implements NameProvider {
  @Foo
  String surname;
  String forename;
  LocalDate dob;

  public String name() {...}
}

When discussing guards, the line length will quickly be breached, so
Brian used a multi line example (even with one guard)

record Person(
    @Foo String surname,
    String forename,
    LocalDate dob)
        implements NameProvider
        requires
             surname != null &&
             surname.isEmpty() &&
             forename!= null &&
             forename.isEmpty() &&
             dob != null &&
             dob.isAfter(LocalDate.of(1880, 1, 1)) &&
             dob.isBefore(LocalDate.now().plusDays(1)) {
  public String name() {...}
}

This record has just three parameters, and my experience suggests a
higher number is more typical.

However, if a longer syntax were the goal, then suddenly a validate()
method makes more sense than a requires keyword:

record Person implements NameProvider {
    @Foo
    String surname;
    String forename;
    LocalDate dob;

    validate {
      ArgChecker.notEmpty(surname, "surname");
      ArgChecker.notEmpty(forename, "forename");
      ArgChecker.between(dob, LocalDate.of(1880, 1, 1),
LocalDate.now().plusDays(1), "dob");
  }
  public String name() {...}
}

ArgChecker would be a standard JDK library. Or the user could choose
their own library. Or they could choose to use the assert keyword. If
mutable, the validator would also be called after every set method,
even via reflection.

More generally, the longer syntax provides a proper location for
documentation, something where the short syntax encourages less
documentation (as people don't like writing multi-line text in @param
today). Annotations would also have a more obvious home (another
feature under discussion where a syntactic style might affect the
outcome of the discussion.)


To summarize, I think there is a danger that records have focused on
one syntactic style (reducing syntax to the absolute minimum), with
the result that the feature doesn't scale well beyond a couple of
fields once real examples are consdered. And as such, decisions may
get taken on semantics because of the syntax, not the other way
around.

Stephen