byKey and byValue: properties or methods?

[Andrei Alexandrescu]

On 1/18/12 12:04 PM, Steven Schveighoffer wrote:
> On Wed, 18 Jan 2012 08:59:57 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 1/18/12 7:20 AM, Steven Schveighoffer wrote:
>>> The only array-specific properties of an array that the compiler should
>>> worry about are ptr and length. Everything else should be a library
>>> function.
>>
>> Even ptr and length should be in the library. The slice structure
>> should be defined in object.d. The only business the compiler has is
>> to lower the T[] type syntax and the [ ... ] literal syntax to
>> .object.Slice!T and .object.slice(...) form, and to make sure that
>> typeof(T[]) is not struct (although factually it is).
>
> That is debatable. The exact semantics of length are not repeatable in
> the library, where a get is a simple field access, yet a set calls a
> method. To achieve the same you would have to require -inline on the
> compile line.
>
> At that point, we have to say "what does it buy us". The function to set
> the length is already a library function, which is changable outside the
> compiler. What do we gain besides saying the language is purer?

1. Offer the runtime the possibility of tweaking the efficiency of the 
abstraction

2. Smaller and simpler compiler

3. Detecting design and implementation bugs in the language (we found a 
lot while porting the associative arrays)

4. Uniform built-in type behavior and user-defined type behavior, which 
is a boon for generic code and generally for the language size and 
understandability

As a related example, look at how simple and efficient byKey and byValue 
are thanks to migrating hashes into the runtime.


Andrei