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