On 2012-04-04 15:01, Simen Kjærås wrote:
Actually, I've thought a little about this. And apart from the tiny idiosyncrasy of $, a..b as a more regular type can bring some interesting enhancements to the language.Consider a..b as simply a set of indices, defined by a start point and an end point. A different index set may be [1,2,4,5], or Strided!(3,4). An index set then works as a filter on a range, returning only those elements whose indices are in the set. We can now redefine opIndex to take either a single index or an index set, as follows: auto opIndex(S)(S set) if (isIndexSet!S) { return set.transform(this); } For an AA, there would be another constraint that the type of elements of the index set match those of the AA keys, of course. Other containers may have other constraints. An index set may or may not be iterable, but it should always supply functionality to check if an index is contained in it. With this framework laid out, we can define these operations on arrays, and have any array be sliceable by an array of integral elements: assert(['a','b','c'][[0,2]] == ['a', 'c']);
I don't think I really understand this idea of an index set. -- /Jacob Carlborg
