Ad hoc type restriction

[Rob Ross]

On Fri, Oct 31, 2025 at 8:10 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Thu, Oct 30, 2025 at 9:38 PM Rob Ross <rob.ross at gmail.com> wrote:
>
>> Contracts, `runtime` and `compile time`...
>>
>
> All good thoughts.
>
>    1. Strongly-typed languages like Java are favored for complex
>    programming tasks because of the rich tools they provide to programmers
>    allowing one to prove to oneself that the code's behavior will be correct.
>    This is Java in a nutshell!
>    2. In general, such tools will operate at *both* compile/build time
>    and runtime - and they should do so in a coherent way.
>
> The observation I'm trying to make in this thread is: Java gives its own
> tools the ability to operate seamlessly across both domains (compile-time
> and runtime) but it makes it difficult for the programmer to add their own
> tools that operate seamlessly across both domains.
>
> -Archie
>
>
I wasn't trying to suggest it was a either/or implementation. Just pointing
out that *some* kinds of preconditions could be completely determined at
compile time, and if so, there may not even be a need for any of those
checks to be included in generated bytecode.

Of course, most checks will require code to execute at runtime. And so the
ability to ignore them (or some of them) at runtime would be an important
feature in this system. Checks facilitate fast-fail program design, which
makes code easier to debug. Checks also impose a runtime penalty that may
not be warranted in mature, well-tested code. That's why I love asserts.
They give me the best of both worlds.

During development, ideally you would program by contract with every
function that takes parameters and returns data. This is the ultimate
safety net. So a system that makes this easy to implement would be a huge
productivity gain. And the ability to turn them off when they are not
needed is a (potential) performance gain.  I see three use case categories
regarding contract programming.

1. Internal, private, "black box" code
2. API code
3. Performant "expert" libraries

1. During development of your private implementation code, programming by
contract has all the benefits discussed in this thread. But since you own
this code, you are in the position to know when it is stable and mature and
calls your internal methods with the correct arguments. You can leave the
checks on during development and on your dev/test systems. But you have the
option to improve performance in production by turning these checks off.
2. API code - since you can't control what foreign code is going to pass
you, these checks will probably need to remain enabled even in production.
3. Expert libraries - think of a C graphics library where speed is
critical. There is likely no error checking at all. You're on the "honor
system" to pass correct data. However, you could still benefit from enabled
checking in dev and test, still catching bugs quicker, and still optimized
for speed in production.

That's why I love the asserts model. My mental picture of them is as a
safety net at a construction site. You put up a net around areas where
people might fall to prevent them from getting hurt. But when the building
is completed, you remove the safety net. The beauty of software as a
"virtual world" is that you can set up and tear down your virtual safety
net with a simple compiler or jvm option flag.

- Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251031/8ea6548e/attachment.htm>