Syntax conflict between multiple type parameter constraints and new function syntax

[Simn]

This doesn't parse:

class Main<T:(a:Int, b:String) -> Void> {
	static public function main() {

	}
}

The parser thinks that the ( is the beginning of a type parameter constraints list. I'm not sure if this is an acceptable limitation because the code clearly looks like it should work, so this could be very confusing for people who don't work on parsers for a living.

[back2dos]

This is unrelated to new function type syntax. Same "problem" with old syntax:

class Foo<T:(Void->Void)->Void> {}

The syntax for a constraint list and TParen already conflict. If we really need to solve this (not sure we do), then my suggestion would be to use [] for constraint lists. Since they are barely working I doubt we'd break that much code.

[Simn]

We could consider introducing & at type-hint level for this specific case. That would be very natural because constraints syntax says "C is A and B".

[back2dos]

I like that. IdeallyA & B would "simply" mean the intersection of A and B, and thus we'd only ever need one constraint.

[Simn]

Right, if | means disjunction/union then & should mean conjunction/intersection. That's actually an argument against using it for constraints: We don't want to create the intersection of two interface/structure constraints because that would mean their common fields.

[back2dos]

Hmm. To the best of my understanding, an intersection type satisfies all of its constituents. This seems to be the case for TypeScript, FlowType and Scala, so chances are I look at this the right way.

It makes sense: consider a type as being the set of all valid values for that type, then an intersection of two types is the set of values that are valid for both types. The intersection of two interfaces would therefore be the type which requires all values to implement both interfaces. Therefore C: A & B means any type C which is a subtype of both A and B, which seems to me to be equivalent to the current C:(A, B).

[Simn]

The terminology has always confused me, but you are right. In that case I revert my opinion from 24 minutes ago and agree that & would be good here.

[ncannasse]

We need to decide for 4.0 final

[ncannasse]

Another option is to replace () by [] not sure which one I prefer but i'm listing alternatives.

[dpomier]

Just a naive suggestion, if the parser thinks that ( is the beginning of a type parameter constraints list, wouldn't it be possible to go until the closing ) and check if it is followed by -> or not? Maybe this doesn't work that easily, but I think the parser could somehow be able to determine if it is a parameter constraints list or a new function syntax

[back2dos]

@dpomier the thing is that (a:A simply won't parse in a place where a type is expected, so you'll never even get to the ->. It would fix the issue with the old function type syntax I brought up.