Context Navigation

Changes between Initial Version and Version 1 of Ticket #36051, comment 3

initial	v1
3	3	In other words, there is a difference between calls of the form `foo(1, 2)` and `foo((1,2))` (or `foo(bar)` where `bar: int \| tuple[int, int]` since `F` is a reference) and trying to automatically turn one into the other seems like it's going to cause more harm than good.
4	4
5		What about we merge both #36042 and this ticket under a single one that adds a `BaseExpression.allows_composite_expression: bool = False` that we set to `True` on `Count` and `TupleLookupMixin` and we make `BaseExpression.resolve_expression` raise a `ValueError` when it's set to `False` and any of its source expression is an instance of `ColPairs`?
	5	To me #36042 and and this ticket should be addressed by introducing a `BaseExpression.allows_composite_expressions: bool = False` that we set to `True` on `Count` and `TupleLookupMixin` and make `BaseExpression.resolve_expression` raise a `ValueError` when it's set to `False` and any of its source expression is an instance of `ColPairs`.
6	6
7	7	Don't get me wrong I think we should define `arity` for `Aggregate` subclasses to guard against improper calls but I don't think that making `Func.resolve_expression` unpack composite expressions is something we should do for the aforementioned reasons.