Usage-site value types: "lowercase" string

[Ali Lahijani]

Hi,

This was originally a question asked by Palo Marton, but that thread
digressed into another discussion, so I want to ask it again here.

Brian has hinted that String may be a lost cause. But to me, it seems that
there is a theoretical migration path for existing final immutable classes
like String, which unlike Optional<T>, have been used since the 90's with
synchronized and ==.

The idea is to move __ByValue from declaration-site to usage-site. One will
keep the definition of String as is, and "String" in source code will
continue to mean Ljava/lang/String; supporting all reference operations
including synchronized. But __ByValue String (or a better syntax like
Palo's lowercase string) will denote Qjava/lang/String;. Method calls
on __ByValue String, including intern(), will be functionally equivalent to
method calls on the boxed version.

The slogan would be: Declaration-site like a class, usage-site like an int!

(Note: Here __ByValue is like a type annotation, not a declaration
annotation, so for example you can say List<__ByValue String>).

To enforce the structural constraints on String, an annotation can be used,
similar to JDK 8's @FunctionalInterface:
@ValueClass
public final class String {...

@ValueClass checks the same structural constraints as the current
proposal's declaration-site __ByValue does. But besides that, it does
nothing. In particular, adding @ValueClass to an existing class does not
change the validity or meaning of any Java program or class file that was
valid before. It's source- and binary-compatible.

On top of @ValueClass and usage-site __ByValue, more appealing high level
language features can be implemented in the compiler. The compiler can
easily implement the current proposal's declaration-site value types
(immutable C# structs) on top of usage-site value types.