I guess I had two main uses, one of which may be invalid!!
-
When working with complex queries I have sometimes found it easier to get consistent results, or at least the optimum results by using full paths in SELECT, rather than the alias that CONTAINS allows. The downside of that is that one cannot ignore parts of the upper path e.g SECTIONS that one wants to ignore for cross-template queries at ENTRY level, for example. Now, I guess that might be down to improper/irregular implementation of CONTAINS , or indeed a feature of descendant paths and CONTAINS, and if so, probably not a good argument, since if done properly // or CONTAINS should return the same resultset.
-
The other, possibly better argument is ease of understanding, conversion to/from other formalisms. The // idea is pretty well-established in xquery and json equivalents, so easier to explain to newbies. Also possibly easier to map between AQL and other higher-level constructs such as GraphQL. I think you might have told me that thinking about AQL resultsets in terms of what Xquery might do is helpful
I guess it is part of the challenge of keeping our stuff familiar where-ever possible. I’m not suggesting dropping CONTAINS as it is very elegant,once you get familar with the rules.
I would expect // to be supported only in so far as CONTAINS is supported, in terms of types. Though I guess it might be possible to have any processing that is not supported by CONTAINS done on the resultset (with an expected performance hit).