byKey and byValue: properties or methods?

[Steven Schveighoffer]

On Wed, 18 Jan 2012 14:11:16 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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

The runtime already implements the abstraction.  All that the compiler  
does special is glue the property to the function call.

> 2. Smaller and simpler compiler

Maybe relevant for new compilers.

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

There is only one function to set length.  It's not quite comparable to  
the entire set of associative array functionality.  Though as someone who  
has mostly rewritten it, I can say it's not a trivial function, and may  
still have bugs in it.  However, I don't see changing the entity who glues  
the property to the function is going to find bugs in the function.

> 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

This I agree with, it makes the language uniformly implemented, which  
makes things simpler to understand/implement.  But it already works, and  
works rather well.  This is my point, all we gain is being able to say the  
language is simpler/purer.

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

Not to mention *possible* :)

-Steve