Most hecs queries yield exactly their Query::Item with a dummy 'static lifetime. The derive(Query) macro takes advantage of this to make both the query type and its item literally the same struct. This fails for structs that contain e.g. With/Without, which transform query types without modifying the Query::Item type; e.g. With<&i32, &bool> has Item type &i32, but is a ZST.
The macro could be modified to generate a separate Item struct where each field's type is the source query's field's Item type. This might be confusing in cases where it's not required, although I suspect few users are directly naming query item types often. The macro could potentially support both modes of operation, but that might increase confusion, and could not be done automatically in any case.
Most hecs queries yield exactly their
Query::Itemwith a dummy'staticlifetime. Thederive(Query)macro takes advantage of this to make both the query type and its item literally the same struct. This fails for structs that contain e.g.With/Without, which transform query types without modifying theQuery::Itemtype; e.g.With<&i32, &bool>hasItemtype&i32, but is a ZST.The macro could be modified to generate a separate
Itemstruct where each field's type is the source query's field'sItemtype. This might be confusing in cases where it's not required, although I suspect few users are directly naming query item types often. The macro could potentially support both modes of operation, but that might increase confusion, and could not be done automatically in any case.