Argumnentation against external function operator overloading is unconvincing

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 25 06:45:01 PDT 2016


On 9/25/16 12:58 PM, pineapple wrote:
> On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis wrote:
>> Considering that a random access range is essentially an abstraction
>> for a dynamic array and that ranges were designed with that in mind, I
>> don't know how you can argue that dynamic arrays shouldn't be treated
>> as ranges.
>>
>> The auto-decoding is certainly an issue, but that only affects ranges
>> of char and wchar. The vast majority of dynamic arrays are perfectly
>> normal ranges.
>>
>> - Jonathan M Davis
>
> Phobos' range facilities vomit when you try to deal with static arrays,
> and they have to be coerced into dynamic arrays before they can be dealt
> with. This is silly.

Yah, it comes as a surprise to many that static arrays are more akin to 
structs than to arrays. They really are records that happen to have 
several elements of the same type. Providing indexing for them is a 
convenience that somewhat adds to the confusion, and converting to 
dynamic arrays is unsafe because it essentially escapes the innards of 
the struct. Statically-sized arrays are odd, that's for sure, and that's 
the case in C and C++ as well.

> It gets under my skin that length and opIndex and opSlice produce
> different results in phobos' ranges depending on one's current position
> in the range. This doesn't make sense to me, and the only reason I can
> conceive of it having become how ranges work throughout phobos is
> because that's how dynamic arrays work if you force them to act as
> though they were ranges.

Better get used to it. Ranges are a generalization of D's slices, not 
the other way around.

> In every single other language I've used, the concept of an Iterable and
> an Iterator are distinct and very separate. An Iterator is something
> that can be iterated over; an Iterable is something which can produce an
> Iterator for iterating over its contents. In D, arrays are Iterables,
> and phobos endeavors to force them to be Iterators as well. It defies
> years of basic design wisdom regarding how to differentiate a collection
> and the means by which one enumerates the items in that collection.

Ranges don't need necessarily an associated Iterable. This is the case 
in other languages, too; Lisp/Scheme/Haskell/etc lists are iterables and 
at the same time their own iterators. But indeed std.container is 
designed to have containers distinct from their associated ranges, which 
raises the interesting question what should happen if a range gets 
"orphaned", i.e. it's still active after its container ceases to exist.

> Arrays are Iterables which should be able to produce an Iterator, in D's
> case a range. They should not themselves be Iterators.

Yah, std.container.Array follows that. It's not an be-all-end-all of 
design though.


Andrei



More information about the Digitalmars-d mailing list