New candidate JEP: 506: Scoped Values

[Adam Gent]

On Tue, Apr 15, 2025, at 1:44 PM, Ron Pressler wrote:
> We gave this matter serious consideration (and even made some changes 
> to the API as a result), reviewed all arguments on both sides of the 
> question, and in the end we didn’t find the case against allowing null 
> less convincing overall than the case for allowing it (especially since 
> users will be able to choose a type argument that allows or disallows 
> null values as they please, and potential extensions of pattern 
> matching make the pattern-matching argument less compelling).
>
> Even if this matter were still open, bringing up the very same 
> arguments that were in front of us when we considered the matter would 
> not lead to a different outcome.
>
> — Ron
>

That is reassuring (and I mean that kindly not satirical or passive aggressive). 

I just wanted to make sure somehow it was not overlooked as I must have missed earlier comments where this was discussed (or perhaps it was internal).

And I'm fairly sure you guys have thought about this more than I have but figured it was worth a just in case comment. My last comment was with Andrew a couple months ago on reddit and I wasn't sure based on their reply if it was cleared up.

Cheers
-Adam

>
>> On 15 Apr 2025, at 17:59, Adam Gent <dev at adamgent.com> wrote:
>> 
>> 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.