New candidate JEP: 506: Scoped Values

[Adam Gent]

It is not really a hill I'm willing to die on but in theory you need to call `isBound` every time you call `get` in the same vain that you need to call `optional.isPresent` before blindly calling `optional.get`.

Consequently the Java ecosystem has tools such as Checkerframework and Intellij that will correctly provide warnings or failure if you blindly call `Optional.get` before `isPresent`. This is of course ditto for accessing `null` and that has even more widespread usage. Now ScopedValue will need this checking where is if it returned null or even Optional it could reuse existing static analysis.

> I suppose we could make ScopedValue<String!>.get() return String?
> instead of String!, so calls to get() always lose non-nullability,
> but that doesn't strike me as a great idea either.

If Valhalla seems close enough maybe instead the `get` can just return an `Optional` which in theory with Valhalla will have less  wrapping cost and you get aforementioned helper methods for free including lazy orElse.

It is just in modern Java `null` being put in a container has been greatly avoided and I think this makes things simpler, easier and safer which If I recall was a goal of ScopedValue?

On Tue, Apr 15, 2025, at 12:47 PM, Andrew Haley wrote:
> On 15/04/2025 17:17, Adam Gent wrote:
>> I actually have problems with the API. I don't think its worth allowing null in a Scoped Value.
>> 
>> I covered this in a reddit commenthttps://www.reddit.com/r/java/comments/1jzd8df/scoped_values_final_in_jdk_25/mn8ofdc/
>> 
>> For those that do not want to go to reddit the gist is I think if we do not allow null in a Scoped Value it makes the API less bloated and easier to use with pattern matching. That is `get` just like a non null value map will return `null` you can do the following and not need the `orElse` or `orElseThrow` and the inevitable plethora of methods that are on `Optional`:
>> 
>> String username = switch(scopedValue.get()) {
>>    case User u -> u.getUsername();
>>    case null -> throw new SomeException("User Missing");
>> }
>> 
>> I had posted earlier about now allowing null but did not get much feedback perhaps because I didn't have enough clarity on why I think it is a good idea not to allow null.
>
> We've been around this several times.
>
> A problem with allowing an unbound scoped value to return null is that
> ScopedValue::get() now introduces nulls even where they don't appear
> in the program. We will be able to fix nullable scoped values in the
> future with non-nullable types, so ScopedValue<String!>,get() will never
> return null.
>
> I suppose we could make ScopedValue<String!>.get() return String?
> instead of String!, so calls to get() always lose non-nullability,
> but that doesn't strike me as a great idea either.
>
> https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ScopedValue.html
> doesn't strike me as a very verbose API.
>
> Andrew.