'$' and opDollar

[spir]

Hello,


[This is another currently unfixed point of D2 that prevents us implementing our project the way we wish it.]

AFAIK, using '$' for custom collection types is not yet possible: oDollar is simply not implemented (correct?). But why do we need it? I do not understand the logic requiring an opDollar special method to "desugarise" the '$' operator. For me, '$' simply means length, so I would be fully happy with the simple rewrite of
    coll[$]  coll[$-i] coll[i..$]
to
    coll[coll.length]   coll[coll.length-i]   coll[i..coll.length]
et caetera.
I have thought at two objections against this.

First, 'length' is not a language-defined special member. Actually, it is already one for the 3 kinds of D arrays --if coll is an array, '$' actually maps to length, I guess. We could extend this principle to programmer-defined collections: make 'length' a special member, just like opIndex or range properties; it is just a decision to take.
Precisely, if needed, index could be either a plain data member _or_ a property, possibly depending on the kind of collection (or rather on whether the designer wants to maintain length or compute it on demand).
Finally, I consider 'length' as already somewhat special for random-access ranges: how else determine index validity, or simply the end point?

Second, length (in the sense of size, or count of elements) may not really make sense for every kind of collections. For instance, there are open, potential, sequences like the set of all integer cubes. Also, there are collections for which the notion of element --thus of count-- is ambiguous or unclear (eg sequences in which elements should be grouped like code unit strings, or trees for which only some nodes hold actual elements,...).
But precisely, I think such non-trivial kinds of collections which do not conceptually have (an obvious) length also do not support '$' (in a simple way). I vaguely have in mind a kind of equivalence class between collections for which indexing/slicing makes full sense and the notion of random-access range with its special attribute 'length'. What so you think?
For what it's worth, python's equivalent to [i..$] ([i:]) is AFAIK actually rewritten to the magic __len__ method for custom types. The equivalent of D's coll[$-1] (coll[-i]) is rewritten to coll[coll.__len__()-i]. I do not know of any practicle issue or limitation of this design in Python --a language in which many features have been fixed or generalised along times.

[OT]
Precisely, has a python-like syntax of negative indices and slice expressions open on right side been considered for D? Like:
    coll[-3]    // third element, counting from right side
    coll[1..-1] // all but first and last elements
    coll[3..]   // all but first 3 elements
and maybe (?)
    coll[..3]   // first 3 elements
I would very much prefere D's explicite notation if ever "$" had any sensible meaning in context. (I also prefere explicite '0' than an open interval on left side.) But as "$" makes no sense, and no other ASCII sign can do the job well, I find python's choice finally better. Also, intervals open on either side would be consistent with D's current use of [], I guess. 
[/OT]


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com