On 2018-03-14T13:10:16 -0400
Brian Goetz <brian.go...@oracle.com> wrote:
>
> One possibility, as discussed, is to attach these as their own thing: 
> "require x > 0", which is code that is narrowly targeted enough to lift.
> 
> Another is to raise the Preconditions library to more than just a 
> library...

To me, it seems like the former would be better in general: A
boolean-valued expression, transformed to a string in a similar manner
to assertions in order to provide a nice error message. I think the
bytecode would probably need to wrap any exception raised by the
expressions in an IllegalStateException that distinguishes it from
an exception raised due to the check failing (I think a check raising
its own exception should be considered to be a bug).

I'd personally not want to see any particular precondition library have
elevated status. Various libraries are designed to work in different
environments. For example, I wrote a small thing that I tend to use
everywhere now that's designed to be zero-allocation in the case of
non-failing checks:

  https://io7m.github.io/jaffirm/

If, for example, the Preconditions library didn't make this guarantee,
then I'd be hesitant to use preconditions on records at all in any
code that did want that zero-allocation guarantee. The point is less
about one API being preferred over another, and more about making sure
that people actually do put validation everywhere because we can give
assurances that the performance is good.

> Either way, though, I think better support for DBC is an orthogonal 
> feature; I don't think it significantly constrains our ability to 
> deliver a records feature without it.

Probably not, no. I must admit that the handling of non-null record
arguments prompted me to bring this up (because adding
Objects.requireNonNull() to every class I ever write adds up to a lot
of boilerplate). I need to go back and read up on the current status of
null handling, but I feel like it'd be nice if it could be handled via
a generic "requires" mechanism along with all of the other checks - if
we don't have a more terse way to say "this field must never be null"
in the field declaration, of course!

-- 
Mark Raynsford | http://www.io7m.com

Reply via email to