I know that smaller queries doing magic is great. But there are other concerns about this. A big one is that the team is focussed right now on fixing bugs and GraphQL specs. Nothing beyond this will be worked in the mid term.
Another point is about how the Query system works. The variables won’t get the predicate used on has func. As it is just a map of uids. Unless it is a value variable. Which you get by expanding the body of the has func e.g:
pred1 as var(func: has(<dgraph.graphql.schema>)) {
realPred1 as <dgraph.graphql.schema>
}
This intersect func needs a lot of contexts to make it work as you want. It needs to infer each block with a complex contextualization that would come in the map - I agree that making things easier write is good, but right now in my opinion cascade does the work.
The rules that need to be applied - in this case, you answered that it would be the predicate used as a parameter in has func. They are not implicit in the variable. The predicates used as parameters are not embedded in the variable. It might be necessary to create a new type of variable for this. Because making it more contextualized will lead to more use of memory unnecessarily for other queries.
It is necessary to discuss the pros and cons when going to simplification.
You said before that it works. But it isn’t desirable cuz you have to write more lines on the query. That is a small cost instead of wait for support for this.
Anyway, feel free to open a request at Dgraph - Discuss Dgraph - My comments aren’t a block. Just giving you suggestions and discussing about the topic.
Cheers.