Disallow Void as type parameter (opt in/out)

[kevinresol]

I found myself adding the NotVoid constraints to every type parameters which is not very convenient. I would prefer disallowing Void as type parameter altogether, with an opt in/out mechanism for people to choose.

p.s. From HaxeFoundation/haxe-evolution#76 I think the direction is to have an unit type and I think we are going to have haxe.NoData so I guess it makes sense to disallow Void

[nadako]

(One of) the idea(s) was to make Void itself the unit type, which would conflict with this proposition. I am curious why this bothers you so much, because I for sure didn't really many have issues with this. Could you provide some example where unit-type-Void wouldn't work?

[kevinresol]

I have already posted some in slack, I will just paste them here:

extern class Logger<T> {
	public function log<T>(v:T):T {
		trace(v);
		return v;
	}
}
var logger:Logger<Void>;

var result = logger.log(??); // what arg to pass in? does it trace? what is held by `result` afterwards?


extern class Promise<T> {
	function then(handler:T->Void);
}
var p:Promise<Void>;

p.then(function() {}); // doesn't work
p.then(function(v) trace(v)); // what to be traced?

What bother me most is the lack of an argument/actual use case to support it (except it is breaking). I see it as a type hole.

[kevinresol]

Also I don't understand why [1].map(function(_) {}) will raise Cannot use Void as value but tink.core.Future.NOISE.map(function(_) {}) will not

[Simn]

[nadako]

IIRC in the current unit-type-Void design both would be allowed and trace null in run-time. Regarding number of arguments - you would still pass a 1-arg function to (arg:Void)->T and you can call with with f(Void). At least that's what I wrote in the proposal.

[kevinresol]

The whole issue is not about unit type actually. What I really mean is that I think allowing Void as type parameter is a bug in the current type system.

And a bug is something that causes problem but has no benefit.

[nadako]

I guess you could say that, but I would make it unit type instead of disallowing it.

[Simn]

I'm memeing, but that's how I actually feel about this. Frankly I don't really care if users explicitly use Void as a type parameter and then run into problems with it. However, I see it differently if there are situations where type inference puts Void in such places and then that causes issues.

[kevinresol]

@Simn it is not me putting the stick in the wheels, but someone else. And I think it is the compiler's task to prevent such silly actions.

@nadako I am not sure about Void as unit type. After years of using tink I think I like using the return type of Noise(tink's unit type) and Void to distinguish a transformation function and a side-effect function.