Empty value types

[John Rose]

Empty value types are perfectly reasonable to instantiate, although there is only one value of each such type (1 = 2^0).

A type Set<T> can be efficiently implemented as Map<T,Unit>, if Unit is an empty value type which is instantiated for each set element. 

It is true that static members of empty types are not interestingly different from non static members. But I don't see a reason to forbid one or the other. If the type implements an interface it needs non static methods. Factories are static. Seems we need both even for the empties. 

Lots of types in FP langs use a unit type, and corresponding unit values, at least for arrow types. Am I missing something here?

– John

> On Aug 1, 2014, at 10:05 AM, Paul Govereau <paul.govereau at oracle.com> wrote:
> 
> I don't think there is anything wrong with it. I can even think of a use case: phantom types.
> 
> final __ByValue class ReadWrite {}
> final __ByValue class ReadOnly {}
> final __ByValue class File<T> { ... }
> 
> File<ReadWrite> openForWrite(String file) { ... }
> File<ReadOnly>  openForRead(String file) { ... }
> 
> void write(File<ReadWrite> file, ...) { ... }
> 
> However, I think we need to add checks to detect construction of empty value types. I am not sure what to do about methods defined inside of an empty type? Maybe only static methods are OK?
> 
> Paul
> 
>> On 08/01/2014 12:50 PM, Brian Goetz wrote:
>> While an empty value is silly, is there something actually wrong with it?
>> 
>> Sent from my iPhone
>> 
>>> On Aug 1, 2014, at 9:47 AM, Paul Govereau <paul.govereau at oracle.com> wrote:
>>> 
>>> What are we going to do with empty value types?
>>> 
>>> The most sensible thing seems to allow them to be declared but not constructed. e.g.
>>> 
>>>  final __ByValue class Void {}   // <- ok
>>> 
>>>  Void v = __Make Void();   // <- error cannot construct empty type.
>>> 
>>> Paul