Should ScopedValue even allow null?

[Adam Gent]

I assume if one did not have a  null sentinel available they could use `Optional<Principal>` ? 

This would be the case of something can be bound but missing correct? Using `Optional` for many might even be more desirable for some that prefer that over dealing with `null` or sentinel. 

Part of what makes me concerned with ScopedValue taking `null` is the confusion with existing methods named `ScopedValue.orElse` (I promise I won't go into poly null): 

See even if you give `orElse` a nonnull as its second parameter you could still get a `null` in the case that null is bound! 

I think that is confusing for folks that have used orElse on `Optional` where if the input is null it will never be null.

On Thu, Jan 30, 2025, at 11:29 AM, Pedro Lamarão wrote:
> Em qui., 30 de jan. de 2025 às 13:21, Adam Gent <me at adamgent.com> escreveu:
>> I had assumed for an embarrassing amount of time that ScopedValue would not allow null. So much so that I could not understand why its API looked like Optional.
>> 
>> Given that ScopedValue goals are to make things easier it seems that not allowing null might be helpful.
>> 
>> Thoughts?
>> 
>> (Alan had mentioned on reddit that this topic was OK and I assume I'm posting in the right place. If not advance apologies.)
> 
> Hi Adam!
> One of the "classic" examples for ScopedValues is communicating the Principal associated with a session in some framework.
> Should we require that frameworks must, for anonymous sessions, set the Principal to some NoPrincipal object instead of null?
> 
> --
> Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250130/9a0b3bd6/attachment.htm>